Voicemail message deleted from mailbox

General Help
1

PBX Firmware: 10.13.66-11
Voicemail 13.0.43

Mailbox is setup to email the voicemail message, and NOT delete after sent. Typically works fine, but have had 3 occasions now where the message gets forwarded and the message is deleted from the mailbox.

Is there a log anywhere that might help determine why this is happening?

Thanks in advance

2

Next time that you will have this issue, check the /var/log/asterisk/full file. It is the asterisk log and there you will see exactly what happend.

3

Thanks for the reply.

I did look at the full file, and I could see the message being left. Then looked at the messages file and could see the email being sent, but I couldn’t find anywhere that the message was deleted or otherwise dealt with.

4

Sorry to resurrect an old thread, but I have actually had this issue on four separate deployments. It happens randomly and different people. I have also reviewed the Asterisk full file and see the message being left but nothing about it being deleted.

Like gw22, when I go into the voicemail settings for extension in question, the the “Email” option is disabled and the “Delete” option is enabled.

In my cases, the users do not have access tot he UCP, so they would not have set this themselves, accidentally or otherwise.

There is definitely a bug in the system that sets this, but no rhyme or reason for it.

If anyone else has come across this and/or knows what is happening, thoughts would be greatly appreciated. It is hard to deploy this as a production-ready system when glitches like this happen, and the best we can do is shrug our shoulders and move on :frowning:

5

I hope you understand that tracking down something like this is near impossible

6

I kind of figured that might be the case. A workaround (and for the interest of anyone else who may encounter this issue), is a script I just whipped up which will check the ‘voicemail.conf’ file for an extension with both “delete=yes” and “email=no” set, then e-mail specified recipients, otherwise it will just quit.

It can then probably be run relatively frequently (15 mins?) and not only alert when such a config exists, but hopefully help narrow down what change(s) were made to trigger this particular config.

    #!/bin/bash

VMCONFIG="/etc/asterisk/voicemail.conf" # Location of voicemail.conf
VMCONFIG_TMP="/tmp/vm-config.txt" # Location of file to write our check results to
EMAIL_RECIPIENTS="" # space-separated list of recipients

# Check the voicemail.conf for the existence of our string and
# write it to our tmp file
grep "attach=no" ${VMCONFIG} | grep "delete=yes" > ${VMCONFIG_TMP}

# Check our tmp file if it is empty or not.  E-mail its contents if not
# empty otherwise quit
if [[ `cat ${VMCONFIG_TMP}` != "" ]]; then
    for email in ${EMAIL_RECIPIENTS}; do
        cat ${VMCONFIG_TMP} | mail -s "VM CONFIG" ${email}
    done
else
  exit 0
fi

I hope this helps someone else out there. If I do find out what particular change(s) seem to trigger this, I will post an update, either in this thread or in a new one (if this one is close)

1 Like
7

Hi There.

So just a small update: early data suggests that this voicemail configuration occurs on its own. I got an e-mail from one of my clients’ systems at 11:01am, and I currently have the script running hourly, meaning it appears to have gotten changed between 10am and 11am.

I checked with the two people besides myself who have access and none of us had made any changes whatsoever.

Oh well. At least I am able to be proactive with it now and fix it when it occurs (or shortly thereafter) instead of an irate client telling me about it and wondering what VMs they lost :slight_smile:

8

Is it possible that your user is setting these params in UCP?

9

Hi Lorne,

No, it is not possible the changes are made in UCP. I actually don’t make the UCP access known to any end users, and in the particular case I posted about, I know for a fact the user does not have access.

10

I have a little more information about this which might help. Twice today I got an e-mail from one of the phone systems I manage that an extension had these particular settings set (different extension each time)

When I dug around in the ‘access_log’ each time, I had found that in the hour prior to when I received the e-mail, each time the extension in question had been recording their Unavailable and Busy greetings via the PhoneApps. Here is a snippet from the log file (identifying information sanitised):

[16/Oct/2017:11:28:48 -0700] "GET /applications.php/voicemail/greetingunavail?linestate=IDLE&user=2267&app_action=record HTTP/1.1" 200 229 "-" "Aastra6867i MAC:XX-XX-XX-XX-XX-XX V:4.1.0.152-SIP"

So it looks like the PhoneApps voicemail module is the culprit here, specifically the recording of greetings, though I only have two example so far; if/when I get more instances, I will check the ‘access_log’ to see if that extension(s) in question were also recording their greetings in the hour prior to the e-mail getting sent.

I may play around with this a bit more too. Usually when I have someone setup their voicemail for the first time, I have them do it via *97, because I set their VM password to the same as their extension, which takes them through the setup wizard, so I don’t think many users initially use the VM app to record their greetings very often. I still imagine this to be a somewhat random occurance, though, because I would think there are thousands of end users who do use the Voicemail PhoneApp to manage/record/re-record their greetings, and it doesn’t seem to be a particularly widespread issue.

Is there something else I can look at to help further narrow this down?