We have just upgraded from 2.4.6-135 TSP 3.0.2 to 2.4.6-161 TSP 6.0.2
Now there is some problems on some call routing rules.
For example, In the call routing, there is a rule called default call handler. It does "Attempt transfer for Opening Greeting" . If a call hit that rule then it gets an error (fail safe message The system is unable to....). If I add one rule just before that with "Send to greeting for Opening Greeting" instead, then it works. Also, when you call a user and the call is transferred to unity on "no answer" then "fail safe" message is played again. If I add a routing rule saying, on forward from user extension XXXX, send to "user greeting YYYY" then it works. So the transfer process seems to be broken (Whatever PHTransfer is) PHGreeting seems to work ok.
Also if a user call voicemail from its ip phone to get messages, he now gets please enter your ID followed by pound, instead of just enter your password
Whenever a call hit the problem, the even logs reports the following error
Event ID 1018
[Port 1] Failed attempting to load database object for application [PHTransfer], specified in routing table rule .
was there more text to that error message in the event log? Was that the only error?
It would appear that the call routing rule itself is referencing a call handler that is not in the directory for some reason. PHTransfer and PHGreeting are just different phone handler (call handler) conversation entry points. One goes to the transfer rule first, then the greeting rule and one goes right to the greeting rule. Both need to load a call handler and if that object is not found in the database you'd get that error or something like it.
If you change the routing rule you added (the one that goes to the greeting for the opening greeing call handler) to attempt transfer instead, do you get the failsafe? I'm wondering if the default routing rule's link to the opening greeting is somehow broken...
sounds more like your default routing rules got hosed up than the default objects in the directory aren't there... you can use ConfigMgr to recreate the routing rules.
You'll find the ConfigMgr located in the \commserver\ConfigMgr.exe
Run it and select the "Run rules Configuration Script" radio button. For the browse button, surf to \commserver\defaultConfiguration\ENU\defaultrules.dcs.
hit the "run" button in the lower right and the snappy little armadillo will jump around for a bit and then return a success (hopefully) dialog. This should reset all your routing rules to defaults and, if all goes well, clear your issue.
IntroductionCUCM Routing RulesDial String implementation PolicyCUCM Routing LogicSIP URI Call Routing Analysis+++ Case Study: 1 ++++++ Case Study: 2 +++Conclusion
Over the last few months, I have had the privilege of working on SI...
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...