[asterisk-dev] Ad: Passing Variables to Voicemail's Email Notification

[Matt Fredrickson]

Just to be clear - in order to create an issue on the issue tracker,
it doesn't require signing a license agreement.  So there shouldn't be
any problems with opening an issue for it.  Hope that's more
straightforward.

Matthew Fredrickson

On Wed, Nov 15, 2017 at 4:08 PM, Matt Fredrickson <creslin at digium.com> wrote:
> On Fri, Nov 10, 2017 at 2:20 PM, butrus.butrus at gmail.com
> <butrus.butrus at gmail.com> wrote:
>> Hello!
>>
>> While playing with Asterisk's voicemail and it's IMAP storage I found
>> a bug - and later I realized how old this bug is. The problem is that
>> variable substitions in voicemal.conf works only with a few specialized
>> VM_* variables set by app_voicemail.so itself. Apparently the bug was
>> discussed here a 10 year ago:
>> http://lists.digium.com/pipermail/asterisk-users/2007-August/194717.html
>>
>> I'm currently using Asterisk 11 (latest version which I can get from
>> backports in Debian Wheezy - which I'm ATM for a couple of reasons stuck
>> with). So I looked into the sources and I think I found the reason and
>> it seems to me quite simple to fix this. I checked the current git and
>> the same problem remains there
>> as well even if a couple of changes were done since Ast11.
>>
>> I fixed the issue for me (i.e. in the Ast11 tree) and even added some
>> small new features (like the possibility to substitute even the "From:"
>> email address, so
>> that I can lookup in the dialplan my addressbook database and if the
>> number is found I can eventually set the email so that the message looks
>> like it came from
>> the person who called me - later on, I added the possibility to change
>> similarly
>> the content-type of the message - now I have HTML messages with
>> hyperlinks to my web interface - and to change the Reply-To:
>> email-header).
>>
>> Now, this is probably not of use for you anyway, since I'll probably not
>> be willing to sign any license agreement with Digum etc (please, do
>> respect it).
>> I however published the patches on github
>> (https://github.com/butrus/asterisk-patches-gpl) so you can take them as
>> an inspiration if you want.
>
> Thanks for letting us know!  Sorry to hear that you're not interested
> in signing the license agreement, but that is a personal choice and
> we'll respect your decision.
>
>> If I understand it well, without the license agreement I cannot even
>> open a bug in the tracker, so I'll describe the problem here so that
>> anyone interested can
>> make a patch against the current HEAD and try to fix it upstreams.
>
> Unfortunately, that is a limitation built into the bug tracker so that
> we don't have any mistakes with regards to licensing conflicts or
> mismatched assumptions on code contributions.
>
>> As mentioned above, the problem is that only variables which the
>> app_voicemail.so itself sets may be substituted. This puzzled me because
>> the ast_str_substitute_variables() function actually needs an asterisk
>> channel in order to do the substitution - and the channel has all the
>> variables you set in the diaplan prior to calling the Voicemail() app.
>>
>> What I found is that the module simply allocates a new channel each time
>> the substitution is done, for example:
>>
>>         if (!ast_strlen_zero(emailsubject) || !
>> ast_strlen_zero(vmu->emailsubject)) {
>>                 char *e_subj = !ast_strlen_zero(vmu->emailsubject) ?
>> vmu->emailsubject : emailsubject;
>>                 struct ast_channel *ast;
>>                 if ((ast = ast_dummy_channel_alloc())) {
>>                         prep_email_sub_vars(ast, vmu, msgnum + 1,
>> context, mailbox, fromfolder, cidnum, cidname, dur, date, category,
>> flag);
>>                         ast_str_substitute_variables(&str1, 0, ast,
>> e_subj);
>>
>> [.................................]
>>
>> Here you can see that for each variable-substitution a new channel is
>> allocated (and later destroyed) and prep_email_sub_vars() is called -
>> which puzzled me a lot because it would be enough to call this function
>> once at the beginning (it prepares the VM_* variables). I actually found
>> what the reason might have been: sometimes cidnum and cidname were
>> passed to prep_email_sub_vars() sometimes it were cidnum_enc and
>> cidname_enc which are variants of cidnum and cidname with control chars
>> and chars > 7bit stripped off.
>>
>> But this is apparently wrong because those strings get escaped (quoted)
>> anyway so that this is not needed at all! So the solution is very
>> simple: just to get
>> rid of any new channel allocation and use the channel inherited from the
>> dialplan. Anyway I tried it and tested and this works for me well and
>> with a little bit of further enhancement to app_voicemail.so this allows
>> me even to do a lot of fancy stuff.
>>
>> So, feel free to take my observations and eventually fix the
>> upstream ;-).
>
> Thanks again for letting us know.  The best place to report bugs is on
> the issue tracker, so if there isn't an open issue for it, that might
> be worth doing as well.
>
> --
> Matthew Fredrickson
> Digium, Inc. | Engineering Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA



-- 
Matthew Fredrickson
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA