CUCM8.5 Troubleshooting

[dbgreekas]

I am having intermittant issues with calls that come in from a PRI through a call router then are sent to a 3rd party system via SIP trunk.

Doing Q931 debugging on the routers to a syslog server I can see calls that ring in but instead of seeing an ALERTING messages (ringing) I see a DISCONNECT message. I can't account for why this happens and end users are reporting hearing ether endess ringing or busy signals. I do not see any line or resource issues at these times they are fairly random and spread out.

Is there any logging I can turn on on the CUCM to my syslog server that might shed more light on these? I can't really turn on full debugging on both the CUCM and the 3rd party system as I am unable to reproduce the intermittant issue and the logging is resource intensive.

[Joseph Martini]

I logging on CUCM isn't resource intensive the system is designed to be able to handle detailed/debug trace level all the time.  I would set the CallManager logs to detailed/debug and wait for the problem to happen and then take a look.  You'll be able to see if the disconnect is from CUCM or from the 3rd party system.

[Aaron Harrison]

Hi

I would check firstly that you have the gateawy registered to the same subscriber that the SIP trunk uses; that way all your debug info is on one server.

I would then enable detailed debugging on that sub for the CallManager service.

Is there a reason why you think this will cause you problems? Is the utilisation that high on these servers?

If the logs are likely to cycle before you can collect them RTMT does have a scheduled log collection tool.

Once you get a report of a failed call, you'll need whoever reports the issue to supply you time/date/calling/called number so you can pull the logs and parse them using TripleCombo to find the specific call.

Regards

Aaron

[dbgreekas]

I was reviewing the debug logs on the gateways again and realized that there was some overlap in call IDs for the messages, after sorting that out and reviewing the CDR log in more detail I have determined that the problem calls are ending with a 102 - Recovery on timer expiry.

There is some information indicating that the T310 timers can be tweeked up to 60s to fix this but I believe that only applies to oubound calls.

Am I correct in thinking that if this error appears on an inbound call that it is actually the calling parties system or the telco that is giving up on the call due to time to answer?

[dbgreekas]

Digging deeper with SIP debugs I can see that the CUCM sends a INVITE that never gets responded to because apparently the 3rd party system is too busy to respond.

The problem is that this is a TCP SIP trunk and apparently the normal INVITE timer does not apply to TCP connections? So the CUCM just rings and rings dispite not getting any SIP response to its invite and then gets all the way to the 60 s call timer on the ISDN part of the call and disconnects.