Fast busy interrupts incoming calls

[pluedke1107]

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 

[yahsiel2004]

What are you using ISDN or SIP?

HTH

Regards,

Yosh

[pluedke1107]

ISDN

[yahsiel2004]

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

HTH

Regards,

Yosh

[pluedke1107]

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.

[yahsiel2004]

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

[pluedke1107]

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

[Jonathan Schulenberg]

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.

[pluedke1107]

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?

[yahsiel2004 · Accepted solution]

Troubleshooting Flowchart

To see more infomation, click the command boxes.

Related Information

• T1           Troubleshooting
• T1           Layer 1 Troubleshooting
• T1           Alarm Troubleshooting
• T1           PRI Troubleshooting
• Hard           Plug Loopback Test
• Technical Support -           Cisco Systems

HTH

Regards,

Yosh

[pluedke1107]

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.