01-15-2020 07:06 AM
As of yesterday users have begun reporting that they're unable to check their VM. They get the MWI, hit the VM button and are prompted for their PIN. Application log in RTMT says the the authentication was successful, but then the users get "The system is temporarily unavailable to complete your call, call again later." There is an event logged in RTMT w/ respect to an error occurring and the caller being played the failsafe messages, but no indication what the error was. And strangely it wasn't working for about 2 hours yesterday, then started working again on it's on (only thing i did was restart a few services which didn't immediately correct the issue so I can't confirm it was related); this morning it has once again stopped. Quick search online points to a reboot as a possible work-around. I'd try that, but this is on a BE so that would take down the phone sysem as well which I can't do during the day.
I enabled all the Macro Traces as well as CsMalUMss, CuDBProxy and CuFileSync.
01-15-2020 09:04 PM
Hi Mumbles,
As you mentioned the problem is occurring on specific time.
This type of fault mostly occurs because of miss-configuration on the Call Handlers.
You should check your call handler configurations.
01-16-2020 05:45 AM
Thanks for the reply. I'll take a look, but the system has been in production for years and this just started 2 days ago. The only recent change was a phone reconfiguration and subsequent mailbox update. And there is no issue leaving voicemail as that is accepted and relayed for users who have that enabled. They are just unable to retrieve voicemail via calling into Unity. The credentials are accepted then they get an error. And this is all users regardless of time.
One thing I noticed is I deleted a user from CUCM so the user was correctly deleted from Unity Connection, but ever since I am getting Java errors trying to load pages in Unity at times. That started yesterday after the initial problem was already present.
01-16-2020 06:03 PM
So as you mentioned that you have done some reconfiguration and it's hard to tell without seeing the logs that what is the exact issue it can be the commands or configuration were run incorrectly and in partial creating corruption and unwanted changes , maybe it is a minor issue. i will suggest if the problem is not resolved go for Cisco TAC.
or do a self analysis of logs using remote port status monitor or RTMT by enabling these
|
Trace to set |
Logs to collect |
Additional Information
|
|||
Macro |
Micro Trace |
Level |
||||
|
Call Routing Issues
|
Call Flow Diagnostics. |
Arbiter |
14,15,16 |
Connection Conversation Manager |
|
Call Control (miu) traces. |
CDL |
All |
||||
Conversation Traces |
ConvSub |
2-5 |
||||
|
CuCsMgr |
10 |
||||
MiuCall |
All |
|||||
MiuGeneral |
All |
|||||
Miu SIP/Skinny |
All |
|||||
MiuSipStack |
All |
|||||
ResourceManager |
10,12 |
|||||
RoutingRules |
11 |
|||||
PhraseServer |
1-3,5-9 |
01-16-2020 07:21 PM
Thanks. Being CUC 7.1.3 I assumed TAC wasn't an option since its not supported any longer. So a reboot seems to have cleared the issue for now. A DRS backup immediately prior failed or errored out on the database for CUC and when the system came back up it was advising that the licensing didn't support the local, but the licenses were still there so i was able to select 1 and install it. I don't know that I collected all of those traces but if it comes back I surely will.
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