[asterisk-dev] Customizable Voicemail Menu

[Giuseppe Sucameli]

2009/5/30 Sean Bright <sean.bright at gmail.com>:
> I'm not really sure why you would necessarily want the voicemail menu
> configuration to be available to non-privileged users.  Also, I don't
> see why "mixing the voicemail and dialplan configuration" is any more
> complex from a management standpoint than throwing:
>
>    #include "voicemail-menus.conf"
>
> at the bottom of my extensions.conf.
>
> So the idea is that users (of the voicemail system) can modify the menu
> layouts for themselves?  Or just that a non-privileged user on the
> server could be made able to change voicemail menu layout?
>

2009/5/30 Giuseppe Sucameli <brush.tyler at gmail.com>:
>> We can keep the voicemail configuration separate  from the
>> dialplan, so the dialplan writer will only have to dispatch the call,
>> and the voicemail config will do the rest. Then one can
>> import/write/modify the voicemail config without having to bother
>> (or needing to have permission) to touch the dialplan itself.

For unprivileged users I intend users with server access but which have a
restricted scope. The dialplan is the main configuration file of asterisk,
instead admin can demand the manage of voicemail to another user.
The inclusion in the dialplan by #include directive is dangerous in this
sense.

2009/5/30 Sean Bright <sean.bright at gmail.com>:
> One of my main concerns with this sample configuration is that we are
> talking about adding another domain specific language to asterisk
> (extensions.conf and AEL2 being the two biggies that spring to mind).

This is the dev mailing list aim: discussing for new code development.
This proposal is as an extension of actual app_voicemail, not a replacement
by a new voicemail.

About the language, I have proposed a possible solution. We can discuss
which is best way to create a config file for voicemail menu using existing
config languages, and when we'll find a solution using it.

2009/5/30 Jonathan Thurman <jthurman42 at gmail.com>:
>> Two file are attached (only text/plain files):
>> > brief.txt
>>                explain the voicemail_menu.conf file structure and its the
>> most
>>                important functionality
>>
>> > voicemail_menu.conf.txt
>>                is an example of config file to customize the voicemail
>> menu
>
> There are some inconsistencies with your example which makes it a little
> hard to follow.  You have the start = ast_vm but no ast_vm section defined,
> did you mean vm_menu?  Also a reference to vm_setup_options when I think you
> meant vm_opt.

Oops, your right... start = vm_menu and vm_setup_options is vm_opt.
I've send the message at 3.23 AM :)

2009/5/30 Jonathan Thurman <jthurman42 at gmail.com>:
> I am really looking forward to customization of voicemail.  It will make
> migrating customers much easier.  However, I think this is a bit in depth.
> So here is an idea.  For basic users: Make it so that you can change the
> digits dialed for the current menu items, and have the prompts say the right
> thing.  For advanced users: export the menu items as dialplan functions
> (maybe have a global variable in voicemail.conf to turn this on/off?) so
> that users can create a more dynamic voicemail application if they so
> choose.  It would also be nice to add some more (admin controlled) abilities
> for the users to change more options (like turning on/off attachments for
> your mailbox)

It's hard, but is a nice idea. However in this moment is a lot in depth.


2009/5/30 Tzafrir Cohen <tzafrir.cohen at xorcom.com>:
> (2) indeed requires major work. Any hope of reusing some of
> app_voicemail's code there?

Yes, is as an extension of app_voicemail functionality.


2009/5/30 Olle E. Johansson <oej at edvina.net>:
>> (1) is by design. I believe that there are good enough samples. Was
>> this
>> ever a problem to anybody recently?
> The idea behind minivm was just to build building blocks to enable
> an extremely high degree of customization in the dialplan, which is
> where we configure this kind of functions. Inventing yet another new
> language is not the right way forward.

Ok, I agree.

>> (3) is an interesting issue of its own.
> I don't really agree, minivm is much better in supporting language
> codes and date syntaxes. You can have multiple mail templates
> in different languages, and set a locale code for correct date formats
> in the e-mail.
>
> I would really love someone
> - Adding channel datastores to minivm to carry account info between apps
> - Adding missing building blocks so that you can build a full
> voicemail app
> - Adding different storage methods for voicemail

In the next GSoC maybe. The next year I'll remember your proposal of love :)


Seriously, I'll wait for your ideas.

-- 
Giuseppe Sucameli