cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
2429
Views
0
Helpful
10
Replies
Highlighted
Beginner

Fast busy interrupts incoming calls

This morning we started experiencing random problems with incoming calls.   A user will receive an incoming call and after being on the call for a minute or more, the call stops and the fast busy signal is heard.     It does not appear that the call is being disconnected since the call length continues to uptick.

It is only happening on incoming calls and it is happening to an array of users scattered throughout the building.     There does not appear to be any pattern.   I have contacted our telco but am wondering if there is anything else I should be looking at.  We are on CM  8.6.2

Thank you-    Pat 

1 ACCEPTED SOLUTION

Accepted Solutions
10 REPLIES 10
Highlighted
Rising star

What are you using ISDN or SIP?

HTH

Regards,

Yosh

HTH Regards, Yosh
Highlighted

ISDN

Highlighted

You can perform a "debug isdn q931" and collect the logs when the call drops.

HTH

Regards,

Yosh

HTH Regards, Yosh
Highlighted

Since it is so random and only happening once every couple of hours, will I  have to stay in debug until it happens again?    Sorry for the basic questions - I am new to CM.

Highlighted

You can leave it running but not for too long as it can be very process intensive. Also verify that you have the buffer logging configured to capture logs (if you do a "show log" and see the debug traces, then logging is configured).

HTH

Regards,

Yosh

HTH Regards, Yosh
Highlighted

Since this is so random I do not think this may be a solution - sometimes the dropped calls are over an hour apart.   Is there any other method of seeing the incoming calls?

Thank you

Highlighted

The request for ISDN Q931 debugs is a valid place to start. We need to understand who is tearing down the call and the gateway is the best place to start. It can clearly identify whether it is something you own (CUCM, the gateway) or the provider.

If it is confirmed to be the router then the next step would be to debug the link (SIP/H323/MGCP) between the router and CUCM. We ask the same question: who starts the teardown? If it turns out to be CUCM then it's time for SDI traces.

Post the debug calling out which call we're supposed to be looking at.

Highlighted

Thank you for the replies.     I logged into the gateway and did a Show Controller T1 and was able to see the three T1 lines.   Within the last 24 hours there has been close to 3000 slip errors and 11000 line code errors.    I have to believe these are circuit errors coming from the telco.   They have tested the circuits but I don't think loop backs provide much  error detecting unless the circuit is down.     Has anyone had this situation?

Highlighted

Thank you for all your input.    By following the flow chart it was easier to see where I should be looking.    The problem did lie with the telco.