Need some help with Voicemail

[Chrishuff1]

A client of mine has a UCM6202 and 8 GXP1625’s.

We have 3 inbound routes based on time. The normal 8-5pm rings 3 extensions and should kick to the VM on Ext 1001 if unanswered. It has been working fine, but all of a sudden its not, without having made any changes. It’s kicking to a generic VM message even though we have recorded one. If I switch to a IVR with only ext 1001 in it, and it goes unanswered, I get the expected VM greeting. Creating a VM group didn’t help either.

We only have 1 VM in the office, so can’t really mess up the destination lol.

[zak706]

Edit the ring group and make sure voicemail is not checked at the bottom.

[Chrishuff1]

Edit the ring group and make sure voicemail is not checked at the bottom.

That doesn’t make sense to me, as when I hover over it, it says “the call would be routed to this destination of no one in the ring group answers the call”…how will it hit a VM if this is disabled?

[zak706]

I was just suggesting that may have happened. If that is not checked, delete the ring group and recreate it. Do you see in the CDR that the call goes to VM? It should show if it’s hitting 1001. Maybe it’s playing the busy msg instead of the unavailable msg. Can you still leave a VM and the phone shows it gets one or delivered via email?

[lpneblett]

My guess, and a big guess, is that each extension can accommodate several different VM greetings which are based upon the condition of the extension at the time when the VM comes into play. However, in this case the call is not being directed as the result of the extension’s condition, but rather that of the ring group when no one answered.

My suggestion is to record a greeting that is similar but somewhat different for all the conditions at the extension and then replicate the call and see which message plays.

I cannot answer why a change unless perhaps a FW update at the UCM sometime in the near past. I guess (again) that the issue may have been around for some time and only recently discovered.

[Chrishuff1]

My guess, and a big guess, is that each extension can accommodate several different VM greetings which are based upon the condition of the extension at the time when the VM comes into play. However, in this case the call is not being directed as the result of the extension’s condition, but rather that of the ring group when no one answered.

My suggestion is to record a greeting that is similar but somewhat different for all the conditions at the extension and then replicate the call and see which message plays.

I cannot answer why a change unless perhaps a FW update at the UCM sometime in the near past. I guess (again) that the issue may have been around for some time and only recently discovered.

Well, we only have 1 VM so it’s easy to differentiate…either its the generic Grandstream VM or our staff member. Thanks for the tip, I’ll give it a go

[lpneblett]

Not sure you are getting my point. I understand that you have one prompt and then a generic prompt and its easy to differentiate between those two, but the question arises not so much as to the prompt, but rather to when the call is sent to the destination VM, which condition does the system see this particular call falling into? -

As you can see, there are a number of conditions and any condition not having a custom greeting will all play the same generic prompt. You can also see there is a priority to the prompts (looking at the top of the snippet).

By recording and a setting a unique prompt for each of the conditions and then doing a call to the RG that goes to the VM destination and hears the unique prompt, you will then know how the system perceived the call condition and why it played the prompt it did earlier.