RFE idea for VM application

Home » Asterisk Users » RFE idea for VM application
Asterisk Users 10 Comments

Hello all,

we are using IMAP for the storage of VMs and had a user yesterday his their maxmsg limit (default 100) and was wondering why nobody could leave them messages. I see in /var/log/asterisk/messages that it does write out a warning message of:

ast_log(LOG_WARNING, “Unable to leave message since we will exceed the maximum number of messages allowed (%u >= %u)n”, msgnum, vmu->maxmsg);

but I was wondering how feasible it would be to modify the code to add:

1) the mailbox name of the user whom has hit the limit
2) a warning/critical threshold that the user is getting close to the limit

using whatever monitoring tool one has available eg. OSSEC the alert could be trapped and the user notified.

Is this worthy of an RFE? and possible help from people if I try and create the patch myself ?

Thoughts or insults ?

10 thoughts on - RFE idea for VM application

  • You don’t state which version this is for, but it seems like a simple patch would be for voicemail to play sorry-mailbox-full.wav (standard sound). In lieu of all that, you could do a quick-and-dirty AGI to read /v/l/a/m and play the message back since voicemail is one of the larger modules and therefore prone to a better chance of error introduction on an RFE. PSOT – the Unix Bot thing was pretty cool.

    Sent: Tuesday, January 24, 2012 8:30 AM

    Hello all,

    we are using IMAP for the storage of VMs and had a user yesterday his their maxmsg limit (default 100) and was wondering why nobody could leave them messages. I see in /var/log/asterisk/messages that it does write out a warning message of:

    ast_log(LOG_WARNING, “Unable to leave message since we will exceed the maximum number of messages allowed (%u >= %u)n”, msgnum, vmu->maxmsg);

    but I was wondering how feasible it would be to modify the code to add:

    1) the mailbox name of the user whom has hit the limit
    2) a warning/critical threshold that the user is getting close to the limit

    using whatever monitoring tool one has available eg. OSSEC the alert could be trapped and the user notified.

    Is this worthy of an RFE? and possible help from people if I try and create the patch myself ?

    Thoughts or insults ?

  • You don’t state which version this is for, but it seems like a simple patch would be for voicemail to play sorry-mailbox-full.wav (standard sound). In lieu of all that, you could do a quick-and-dirty AGI to read /v/l/a/m and play the message back since voicemail is one of the larger modules and therefore prone to a better chance of error introduction on an RFE. PSOT – the Unix Bot thing was pretty cool.

    Sent: Tuesday, January 24, 2012 8:30 AM

    Hello all,

    we are using IMAP for the storage of VMs and had a user yesterday his their maxmsg limit (default 100) and was wondering why nobody could leave them messages. I see in /var/log/asterisk/messages that it does write out a warning message of:

    ast_log(LOG_WARNING, “Unable to leave message since we will exceed the maximum number of messages allowed (%u >= %u)n”, msgnum, vmu->maxmsg);

    but I was wondering how feasible it would be to modify the code to add:

    1) the mailbox name of the user whom has hit the limit
    2) a warning/critical threshold that the user is getting close to the limit

    using whatever monitoring tool one has available eg. OSSEC the alert could be trapped and the user notified.

    Is this worthy of an RFE? and possible help from people if I try and create the patch myself ?

    Thoughts or insults ?

  • This is in version 1.8 and 10.0 from what I can see. The problem is not that the caller is unaware of the recipients mailbox being full, as they do hear the message, but it is the recipient whom may be completely unaware. If a more verbose warning message was written out we could at least alert the user to the issue. They could then perform some timely and necessary mailbox clean up:)

  • I would personally rather use a stand-alone daemon to query the mailboxes and send an email to the box owner when he or she reaches a tolerance level rather than depend on an overloaded application that is running God-only-knows what modifications to the original intent (IMAP, Real-Time, Active Directory, any other monkey wrench someone might throw at the original idea of a text file and wav on the actual host). Voicemail.conf presumably has the email of the box owner and the number of messages they can receive. I would suggest adding a warnmsg= to voicemail.conf to work in tandem with maxmsg=. Warnmsg could be a count of messages to send warning at or a percentage of maxmsg. If I ever get a free day, I might try this.

    Sent: Tuesday, January 24, 2012 8:56 AM

    This is in version 1.8 and 10.0 from what I can see. The problem is not that the caller is unaware of the recipients mailbox being full, as they do hear the message, but it is the recipient whom may be completely unaware. If a more verbose warning message was written out we could at least alert the user to the issue. They could then perform some timely and necessary mailbox clean up:)

  • Hi Danny,

    Yes I did think about a stand-daemon to do exactly that; and on a side note was even considering using Node.JS 🙂 Though the rationale for considering making the change in app_voicemail.c is that for it to alert on maxmsg it must have already calculated the number of messages in the first place so no real overhead should be introduced. Your suggestion makes perfect sense, and one I had discussed with a colleague, so will have a hack this evening on V10 and see if it would be easy to implement and back port.

  • Ah, but what you have here is a classic “break glass to release hammer”
    situation. The intended recipient doesn’t know that their voicemail box is
    full; but, evidently from the fact that they are accruing voicemails at all,
    they must, for some unspecified reason, not be contactable by telephone!

    All you can do in that situation is mention in your “mailbox full” message an
    alternative means of contacting the intended recipient …..

  • The RFE was to fix Asterisk, not the user who can’t be taught. If the
    recipient can’t/won’t answer their phone and can’t/won’t read their email,
    they are beyond help.

  • In the “classic” environment, you can move a “read” email from INBOX to OLD.
    If the user thinks the content should be saved, that’s the route I would
    recommend.