Asterisk Voicemail Redesign

This page is dedicated to what the future voicemail app needs to based on. The voicemail app has being made using certain guidelines that aren't proper for future needs.

To start, here is a brain storm of items to think about when rebuilding the future voicemail app

• Key Map configurable
• text config AND database ready
• having context for configuring user mailbox
• have a 'manager' interface to integrate with external Clients.
• only save in * raw file format
• be safe when writing voicemail, record in a temporary folder and after move it to the user mailbox
• create a 'VoiceMail Net' or something else, a Asterisk Network, a bunch of * box talking to each other about stuff they share, like a central voicemail server

I beleive not EVERYTHING should be within * app. For example, the process of emailing a voicemail should be dedicated to a external deamon that monitor 1 or multiple manager interface, so that deamon can be optimized or changed as the user need, without affecting the pbx in a whole. The voicemail App should not have to be changed. everything should be configurable, and if a section can be changed too much, just take it out of there.

here are sample options to be added

• be able to go forward x second or backward x second
• have pager # or phone number notifications
• be able to set on the phone, a paget's #, or number to get notification of voicemail
• be able to set a temporary out of the office message
• if posible, be able to set prompt in different language

Maybe just get a list of feature from an Octel system, and put them in *

With a manager interface, we could make Application that run on the user desk to manage their voicemail. Playback could be done in different way, maybe just open a port on the server, and tell the client to connect to it to get the audio stream, or stream it via a IAX stream with the win or linux iax library ???

NOTE: don't integrate IMAP system WITHIN voicemail, make an app that monitors the manager interface, and apply items to the IMAP directory structure.
NOTE2: Why not on Linux create a FUSE to gain the MAILdir functionality.

AGREED. However, instead of all that monitoring and Manager interface mangling, what about just changing the voicemail system to store mailboxes in maildir format?

• voicemail expiration is trivialized: maildir doesn't use numbered files
• maildir storage format is fail-safe
• IMAP access via any IMAP server which supports maildir (like Courier IMAP for example)
• many maildir tools out there for managing the mailboxes
• maildir can support quotas on a per-mailbox basis (maildir++)
• folder support (maildir++)

Basic refactoring

I (chops) have started working on refactoring the voicemail app to make some of these things easier, and to further my work on the IMAP/Voicemail integration bounty. I'm going to start putting some basic patches in Mantis soon. In general, what I think should happen to app_voicemail.c in the near future is:

• Abstract storage into a struct of function pointers instead of the #ifdef blocks that are there currently.
• Abstract messages into a struct ast_vm_message, with a small set of functions to operate on them, instead of the current un-abstracted approach.
• Change messages to be stored on disk by their unique IDs instead of stored by number and constantly re-sorted.

So far I have three patches in Mantis (more for discussion than in the expectation they'll be immediately applied, though I'd be happy if they were):

• Cosmetic cleanup of 'mailbox' vs. 'ext' vs. 'folder' in app_voicemail.c: here
• Abstract storage of voicemails into a struct interface instead of a block of #defines: here
• Initial stab at abstracting voicemail messages into a struct and accessor functions: here

The third is by far the most interesting; the other two are just sort of general cleanliness things. The abstraction of messages is what I really think is important and difficult. I'd be very interested in anyone's feedback on my ideas and patches.