Failsafe message received on external calls

[admin_2]

We are currently receiving the "system is unable to complete your call" failsafe message for calls coming through the PSTN gateway (AS5300 running 12.2.2XA) to the Unity polit number. CM version is 3.0.10 with Unity 2.4.6 and version 32 of the AV TSP.<br><br>The application log is getting hit with the following error message each time (AvConvMsg_MC)<br><br>IAvCallHandler::get_Recipient returned [0x8004200c] on line 1813 of file h:\CommSvr\Sources\AvConvPhoneHandler\AvConvPHGreetingSvr\AvSPlayGreeting.cpp <br><br>Running conversation PHGreeting on Port 3 <br><br>GetCallHandlerProperties returned [0x8004200c] on line 440 of file h:\CommSvr\Sources\AvConvPhoneHandler\AvConvPHGreetingSvr\AvSPlayGreeting.cpp <br><br>Running conversation PHGreeting on Port 3<br><br>Status monitor in the techtools directory shows the failsafe being played on the Unity<->CM port that picks up the call.<br><br>The same result is being received for IP phones that do not have a subscriber associated with their directory number. Allocated extension get the attempt sign-in prompts as expected.<br><br>The problem doesn't seem to exist for forwarded calls - for example if an external call goes directly to a extension and then forwards to the voice mail pilot, the appropriate greeting is played.<br><br>Is there anything I should be looking for in the way broken call handlers for direct calls<br><br>Any suggestions would be appreciated<br><br>Thanks in advance<br><br>Cam.<br><br><br>

[#2]

Thanks for the excellent description of the problem. Back when sites were running TSP 28, many people had to adjust the routing rules to overcome a defect when port 1 was busy and another call came into Unity. Adjusting the routing rules might very well be causing the problem. Were there any changes to the routing rules? If so, were there heavy changes, or just a small one?

Steve Olivier
Software Engineer
Cisco Systems

[#3]

Thanks for your response Steve. I know the routing rule you are referring to in v28. I did have that additional attempt sign-in rule in place but after realising 32 addressed that problem - I have removed it! The problem was evident before putting it in and still now without it!

Thanks

Cam.

[#4]

you might want to rerun the default rules configuration script just in case it's not happy with the rule order or something.

Run ConfigMgr.exe out of the \commserver directory and select to run the rules configuration script. Browse to \commserver\Localize\DefaultConfiguration\ENU\ and select "DefaultRules.DCS". After it completes you'll need to restart Unity and then give it a whirl.

if you're still getting failsafe after that you have a new and exciting problem we'll have to get into your system and look at.


Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

[#5]

Jeff - thanks I will try this tonight when we can get an outage window. Will post again tomorrow to let know the result.

Cheers

Cam.

[#6]

Jeff - quick update on how we went with the ConfigMgr rule rebuild. It completed successfully and after the restart of the Unity server, the failsafe message was still being received and error logged to the app log.

Working with the local tac, we went one step further whilst we had the outage and loaded the DefaultDatabase.dcs file in ConfigMgr.exe and selected the Doh option. After the restart this time, the failsafe had been replaced by another message "Sorry opening greeting is busy or does not answer. Sorry there is no operator available at this hour ... blah, blah". There are no errors being logged to the application log now.

I got another copy of the opening greeting and through the call handlers webpage set the option - paste from file to this new file - still got the same message.

So I guess there must be still a link out of place somewhere - any suggestions would be great.

Cheers

Cam.

[#7]

If you're getting "the opening greeting is not available" prompt, you must have an ID assigned to that call handler and the call must be coming in as reported to be forwarded from that extension... there's no other scenario that will force that message to come up.

If you've got 126 and TSP 32 on here and you're STILL getting forwarded calls reported when you dial the hunt group directly, something very strange is going on ... everyone else that applied this was cleared up in short order.

We'll have to get in and take a look at what you've got going on there... I have no other suggestions to make assuming all the information provided here is accurate.


Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)