[asterisk-dev] voicemail_menu_branch [was: Re: [svn-commits] brushtyler: branch brushtyler/voicemail_menu_branch r199855 - in /team/brusht...]

Giuseppe Sucameli brush.tyler at gmail.com
Mon Jun 29 11:50:57 CDT 2009


Hi,
I'm sorry for my reply so late, but I had some exams.
For the last committ, I have explained my reasons bottom..

2009/6/11 Tzafrir Cohen <tzafrir.cohen at xorcom.com>:
>> +A few notes on the proposed architecture for the new voicemail application.
>
> There are two "applications" that take their data from voicemail.conf.
> The other one is Directory. Should the menu be limited to the voicemail?

The Directory app use the voicemail.conf, but no modification are required
at voicemail.conf.
I don't know what relation you have finded between the Voicemail app menu
and Directory.

>> +        max_retries = n
>> +            ; number of maximum failed authentication before Asterisk closes
>> +            ; the communication channel
>
> Why is that relevant to the menu? Shoudn't that affect VMAuthenticate
> as well?

You're right, it's wrong...
max_retries is the max number of consecutive default action
execution if the user insert no pattern or inserted patterns
doesn't match.

>> +        forward_key = #
>> +            ; set the key to forward the playing message
>> +        reverse_key = *
>> +            ; set the key to reverse the playing message
>> +        pause_key   = 0
>> +            ; set the key to pause the playing message
>> +        stop_key    = 2
>> +            ; set the key to stop the playing message
>> +        restart_key = 1
>> +            ; set the key to restart the playing message
>
> Such global settings seem to me against the spirit of the dialplan.
>
> How can you override it locally?
>
> * Multi-tennant setup (per-context setup)
> * Some users have different phones / terminals (per device? per user?)

In this moment these keys are harded in app_voicemail.c code,
this is a first solution.

>> +[vm_menu]
>> +    init = SET(FOLD=${IF(${VMCOUNT(id at mb,INBOX)}?NEW_FOLDER:OLD_FOLDER)}),play(vm_intro)
>
> As ugly as the dialplan itself at its worse.
>
> By limiting the condition to a single line you leave the sysadmin no
> option to break a long calcualtion to shorter and more readable steps.
>
> Let's see if I parsed it correctly:
>
>  If you have messages from user 'id' on box 'mb' (are those plain
>  strings or some magic names?) jump into 'NEW_FOLDER', else - jump into
>  'OLD_FOLDER'.
>> +        ; set in FOLD var the working folder
>
> I missed it. It just sets a variable.

Yes :)
No, "id" and "mb" are only strings, I have changed
the example. I've insert VM_USER and VM_CONTEXT
to retrieve these informations.

>>  [...]
>> +
>> +[change_folder_menu]
>> +    init    = play(vm_change_folder_intro)
>> +    default = play(vm_change_folder_intro)
>> +    1       = change_to(work), return(1)
>> +    2       = change_to(family), return(1)
>> +    3       = change_to(friends), return(1)
>> +    4       = change_to(cust1), return(1)
>> +    5       = change_to(cust2), return(1)
>> +    6       = change_to(cust2), return(1)
>> +    7       = change_to(cust3), return(1)
>> +    8       = change_to(cust4), return(1)
>> +    9       = change_to(cust5), return(1)
>> +    *       = return(1)         ; return Main Menu
>
> Sriking similarity to previous menu. If your motivation not to
> use minivm is to avoid boilerplate code, ask yourself why you get so much
> boilerplate code here. E.g. 'return(1)'.

You're right because in this example we have only 2 command
per line and we cannot shink the code.
If there are almost 3 command, we can make a call to
another menu, as i.e.:

[menu1]
1 = SET(VM_FOLDER=Work), call(change_return)
2 = SET(VM_FOLDER=Family), call(change_return)

[change_return]
init = change_to(${VM_FOLDER}), return(2)

This is a possible solution to shink codes, as minivm macro...

I have created 2 voicemail_menu.conf that replies the
actual voicemail menu. I'll committ these files this
today (I'm making some tests) together with some
fixes to the code.

-- 
Giuseppe Sucameli



More information about the asterisk-dev mailing list