VMX: Exactly why is unavail.wav REQUIRED?

I spent a bunch of time this evening trying to figure out a problem with VMX Locator. I ran into another thread in this section that pointed to bug # 2046 : VmX Doesn’t work. I looked though the extensions.conf and the fix is indeed there. Ok, so I was confused and spent s’more time tracking down the problem.

This was in the CLI debug output:
– Executing NoOp(“SIP/225-0978f798”, “”) in new stack
– Executing AGI(“SIP/225-0978f798”,
“checksound.agi|/var/spool/asterisk/voicemail/default/227/unavail”) in new stack
– Launched AGI Script /var/lib/asterisk/agi-bin/checksound.agi
checksound.agi|/var/spool/asterisk/voicemail/default/227/unavail: VmX requires : /var/spool/asterisk/voicemail/default/227/unavail.wav or .WAV exist in order to function

My question is: why, exactly, is unavail.wav REQUIRED?

If there is some system limitation that causes this restriction, the VMX UI should not allow the VMX settings to be enabled - the page should have everything greyed out with a message telling the user that they have to record an unavail message if they wish to use that functionality. As it is, it’s a lousy user experience: the functionality does not work and the user has no way of discovering the reason. (Of course, ideally, if having an unavail.wav is not actually some Asterisk requirement, then the script in extensions.conf shouldn’t require it and this whole paragraph may be ignored. :slight_smile: )


so what if there is a message there, it is enabled, and then the message is removed. An admin need to be able to enable it. A user needs to be able to control it. And the system needs to be able to act rationally when a user calls in if there is not message.

What may be helpful is for the User Portal to provide feedback to the user if no message is there. But User Portal work is at a minimum until we replace ARI.

Thanks for the swift response. However, I’m missing something: why does the existence of the unavail.wav file change whether admins and users can control VmX info? When a incoming call hits the VmX path, if the file is there, it’s played, if it’s not there, the system plays the default unavailable message. And then, in either case, the buttons are enabled to allow VmX stuff. It seems straight-forward to me, perhaps I don’t know enough about the way that script works…

I’ll see if I can find a bit of time to scope out what it would take to provide the user with info on what’s going on in the case where no unavail.wav exists.