VM Pro AA Callflow

[cmnstr]

I am sure I have done this before but for some reason it isn't working. Not sure if something changed in newer versions of software but here is the issue:
VMPro
I have a customer that wants a AA during the day and a general mailbox at night controlled by a button. So, I created a empty hunt group 255 that answers the incoming call and I set up the group start point in VM Pro as a Leave option that redirects the call to the MAINAA module when the hunt group 255 is in service. This part works perfectly.

In the 255 group in Manager, I have set the Night service destination to 256 so if the call comes in while 255 is in Night service the call should go to mailbox 256. However, no matter what I do, the call continues to go to the AA as if 255 answers the call. I also tried to change it to out of service instead of night service to point it to 256 but the same thing happens.

Have I missed something? I haven't had to configure a system this way in quite some time but I am certain I have set it up this exact way in the past and it worked.

 

[derfloh]

I would point the ICR to VM:MAINAA

There I would build a 'switch' that checks the group status (In Service, OOS, Night Service) and sends the call to either the AA (In Service) or into one Mailbox (VM Leave Action). No Need to send the call to the group itself.

Nevertheless. If The group service status is not correctly recognized by the system this will be a problem.

IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN

 

[cmnstr]

I was looking for a way in VM Pro to check that hunt group to see if that would work instead of doing through ICR to a hunt group sending the call to the AA. Do you have an example of how to create that, or point me in the right direction?

 

[Ekster]

Why not use a time profile on the incoming call route and set a button on the phone (Time Profile) that will latch the time profile active/inactive as required?

“Some humans would do anything to see if it was possible to do it.
If you put a large switch in some cave somewhere, with a sign on it saying 'End-of-the-World Switch. PLEASE DO NOT TOUCH'.
The paint wouldn't even have time to dry.”

Terry Pratchet

 

[TouchToneTommy]

Remove the Night Service destination on Group 255. All calls to 255 hit Voicemail. Check if 255 is IN service or not (NS or OOS). If IN service send call to MAINAA, if NOT send call to voicemail

 

[derfloh]

Maybe I wasn't clear enough but my suggestion was exactly what TouchToneTommy told.

IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN

 

[cmnstr]

Thanks guys. It was the generic token settings that I was missing when I tried to do it. All good now other than one small issue when the call goes to 256. When group 255 is in Night service and the call routes to 256, you hear "Your call has been answered by Avaya IP Office" before dropping to the custom greeting. That's a minor issue though since the caller will hear the greeting eventually before leaving a message.

 

[derfloh]

Instead of "Leave Message" you can send the call to a "Voice Question" (hope this is the correct name in english). Add an announcement and let the caller record up to x seconds. You can set which Mailbox should receive the left message.

IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN

 

[TouchToneTommy]

you hear "Your call has been answered by Avaya IP Office" before dropping to the custom greeting.

Sounds like you either recorded your greeting in the Name recording, or you haven't activated the correct recording

 

[cmnstr]

Customer recorded it himself so anything is possible. Will look into it tomorrow but my guess is likely user error.