Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Calls are unanswered when VMpro is down, 1

Status
Not open for further replies.
Squatch

Squatch

Technical User
Jul 19, 2012
11
US
The client has an IP Office 406V2 with Voicemail Pro.

They have an auto attendant ON/OFF button for daytime control of incoming calls. When auto attendant ON is selected, calls go to a short code that goes to a VMPro short code that invokes the main auto attendant. It works very well - until something happens to the VMPro PC. When VMPro is unavailable, inbound calls do not ring any phones. Callers just hear ringing.

The IP Office Short Code is *231, Feature is Voicemail Node, Telephone number is AAFWD.
AAFWD is a VMPro Short Code having a GO TO statement doing to the MainMenu Module. This arrangement is not broken, so I haven't messed with it.

There must be a better way to arrange the flow of calls to make the Main hunt group ring when auto attendant is ON, but VMPro is unavailable. The IT group has been inconsiderate lately with network and Domain changes, which make the "phone Stuff" look bad when it goes down. Any Suggestions?
 
Sort by date Sort by votes
Indeed, there must be a better way.
Route calls straight to voicemail and use a generic action to control the huntgroup status (i think they use that)
Then use a variable check to route the calls to the right place.


BAZINGA!

I'm not insane, my mother had me tested!

 
Upvote 0 Downvote
have you run a system status to see what is happening?

acss sme acis sme acss cm 5.2.1 acss cm and cmm
 
Upvote 0 Downvote
On the IP500 mine says "The Incoming Call Route targets the Voicemail Module Backdoor. If a hunt group is created with the name Backdoor then if the voicemail was unavailable the call would route to this hunt group." Not sure about the 406 but on the IP500 I always create a a huntgroup with the module name so when my IT guy gets an itch to change stuff without me knowing and the server goes down, it still rings the group. Is this what you are referring to?
 
Upvote 0 Downvote
why not use the incoming route fallback destination for call destined to vm on the incoming route?

The primary destination becomes the vm:callflow and the fallback destination becomes the vmdown group.

 
Upvote 0 Downvote
Fallback destination on incoming call route will solve the problem, but we don't know what version the 406 is. It has been a while, but I remember the fallback not being present a long time ago. Problem with the hunt group named the same as the module is that this sounds like a shortcode in the PBX which can't directly access a module.

Make a module named the same as the hunt group that tests a variable like tlpeter suggested and send the call where it needs to go depending on that. Have the incoming call route target the module. Change the Day On/Off button to dial a shortcode that calls a voicemail shortcode that changes the value of the user variable. The group should always be in service. If the VM is down, then the phones will ring.

Or upgrade the 406v2 and use the fallback destination setting.

Oh, and plug the voicemail into one of the 406 LAN ports, oh, even better, unplug the data network from the 406 also. Sometimes you have to prove it's not you or your equipment, even if just for yourself.
 
Upvote 0 Downvote
I really appreciate the responses to my post. I was particularly enlightened by piethief's clarity. None of this was simple until i did it. Then it's obvious.

Regarding my IP Office 406V2 with R5, the problem has been that when the auto attendant (AA) is the main answering point, no phones ring when the Voicemail Pro is unavailable. Customers calling in just hear ringing. After all the posts, here's what I did to handle the problem
1) In Voicemail Pro, I created a User Variable named "AA On or Off"
2) Created a two step module to test the On/Off status of the AA variable and play a .wav to tell whether it is on or off, then used a menu to invite the user to set it on or off.
3) Created an IP Office Short Code that goes to the module in step 2
4) Inserted a Test User Variable module after the Start Point in the original auto attendant. That Action results in a TRUE or False. If the "AA On or Off" variable is TRUE, the flow goes into the original attendant. If False, the caller is transferred to the Main hunt group.
5) I Gave the auto attendant module the name "Main" SAME NAME AS THE HUNT GROUP. When the Voicemail PC is out of service, the IP office rings the hunt group having the name of the unreachable module.
6) Changed the default Incoming Call Route to go to VM:Main, the Voicemail Pro's auto attendant. No Fallback is selected.

Do you see any holes or gotcha's in this?
 
Upvote 0 Downvote
no that is what should work.


Joe W.

FHandw, ACSS (SME), ACIS (SME)



Give a tech a solution and he will be back tomorrow to ask you the next question, teach a tech how to read the manual and he will be able to solve the problems for a life time.
 
Upvote 0 Downvote
sorry, reading over my post again I should have said

no holes or gotchas that I could see and this should work

Joe W.

FHandw, ACSS (SME), ACIS (SME)



Give a tech a solution and he will be back tomorrow to ask you the next question, teach a tech how to read the manual and he will be able to solve the problems for a life time.
 
Upvote 0 Downvote
You make it way to complicated.
Build a group VMDOWN and put some phones in it.
Put this group as destination in the fallback destination.
When VMPro is down then it rings this group and shows the groupname.
Using user variables is not needed to get this working.


BAZINGA!

I'm not insane, my mother had me tested!

 
Upvote 0 Downvote
have you tried it lately tlpeter?
I gave up on it a while ago because it only works when vm is completely down, as long as the vm IP address is still responding and something happens I never got it to work.
It might work now (I think last time I did it was R6.1 or so

Joe W.

FHandw, ACSS (SME), ACIS (SME)



Give a tech a solution and he will be back tomorrow to ask you the next question, teach a tech how to read the manual and he will be able to solve the problems for a life time.
 
Upvote 0 Downvote
Hi TLPeter, I'd love to make it simpler. I like the VMDOWN notification.
Still, I don't see a shorter way to provide AA status to the user, the AA On/Off control and the fallback plan without all these steps.

By aiming inbound calls to the IP Office hunt group, you can see and control the AA status on the phone button - but you lose control of the call, with no fallback.

By aiming inbound calls to VMPro, You get two kinds of fallback but you lose AA the status and control - unless you build it.

What could I chop out?
 
Upvote 0 Downvote
If VMPro is down then yes there is no voicemail but the server should not bedown just like the IPO should not be down.
Fix the problem instead of fixing the result of the problem :)
It can happen that VM is down but then at least the calls are presented at the users.


BAZINGA!

I'm not insane, my mother had me tested!

 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

L
  • Locked
  • Question
VMPro+Office365
Replies
5
Views
369
lizarazo
L
William C290
  • Locked
  • Question
Distributed VMPro 2
Replies
8
Views
1K
derfloh
derfloh
Anonas
  • Question
MS SQL integration with VMPro
Replies
1
Views
108
dencom
dencom
quazimotto
  • Locked
  • Question
VMPro TFTP Accesss: Password BAD 1
Replies
5
Views
498
Travis Harper
Travis Harper
BrianCosta
  • Locked
  • Question
VMPro and prompts 8
Replies
1
Views
191
sizbut
sizbut

Part and Inventory Search

Sponsor

Back
Top