[asterisk-bugs] [JIRA] (ASTERISK-29349) Silent voicemail option is not completely silent

[N A (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-29349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=254601#comment-254601 ] 

N A edited comment on ASTERISK-29349 at 4/15/21 3:17 PM:
---------------------------------------------------------

I've been working on this and am essentially done with the required patch. The new option is an option with an optional argument, which, if specified, will play a different beep, and if nothing is provided as an argument, no beep will be played at all.

My only problem is in trying to do this:
                       else if (!ast_strlen_zero(opts[OPT_ARG_BEEP_TONE])) { /* custom beep */
                                res = ast_stream_and_wait(chan, opts[OPT_ARG_BEEP_TONE], "");
                        }

opts doesn't exist in leave_voicemail, though.

All the options seem to get passed in in leave_options, but this contains only options and not the argument. Just wondering if it would be problematic to pass in the arg directly.


was (Author: interlinked):
I've been working on this and am essentially done with the required patch. The new option is an option with an optional argument, which, if specified, will play a different beep, and if nothing is provided as an argument, no beep will be played at all.

My only problem is in trying to do this:
                       else if (!ast_strlen_zero(opts[OPT_ARG_BEEP_TONE])) { /* custom beep */
                                res = ast_stream_and_wait(chan, opts[OPT_ARG_BEEP_TONE], "");
                        }

The opts array doesn't get initialized until around line 11,500, and I'm trying to use one of the options way up around line 6,940.

I don't want to re-architect the whole thing by moving the option initialization way up in the code, since this is supposed to be an addition and not change any existing behavior. Would the appropriate thing to do here be try to read just this option without using opts? It seems I can use ast_test_flag to see if an option exists, but not actually read it, and I'm not seeing an equivalent for arguments to options. Other cases that require this, such as the d option, use a global variable.

> Silent voicemail option is not completely silent
> ------------------------------------------------
>
>                 Key: ASTERISK-29349
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29349
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Applications/app_voicemail
>    Affects Versions: 18.2.0
>         Environment: Debian 10
>            Reporter: N A
>
> I don't think this is necessarily a bug, but it is a drawback or caveat of the VoiceMail() application which, in my opinion, is non-sensical behavior.
> I play my own audio files before going to the VoiceMail() application in Asterisk. This includes using custom beep tones as opposed to the default beep file that is provided. My problem is that the s option (skip instructions) does not suppress the beep. As a result, the workaround I have been using for several years is now to replace beep.ulaw with a short, silent audio file, so that callers do not hear two beeps. This is demonstrated below:
> [Mar 16 12:48:11]     -- Executing [2311131 at tad:6] VoiceMail("Local/2311131 at tad-000022cd;2", "2311131 at default,s") in new stack
> [Mar 16 12:48:11]     -- <Local/2311131 at tad-000022cd;2> Playing 'beep.ulaw' (language 'en')
> [Mar 16 12:48:12]     -- Recording the message
> [Mar 16 12:48:12]     -- x=0, open writing:  /var/spool/asterisk/voicemail/default/2311131/tmp/MITIHK format: wav49, 0x7f7ae020be00
> [Mar 16 12:48:12]     -- x=1, open writing:  /var/spool/asterisk/voicemail/default/2311131/tmp/MITIHK format: gsm, 0x7f7ae01a0d20
> [Mar 16 12:48:12]     -- x=2, open writing:  /var/spool/asterisk/voicemail/default/2311131/tmp/MITIHK format: wav, 0x7f7ae0250e90
> I have a global variable called ${beep} I can use if I want to play an actual beep.
> The problem here arises if I want to use the VoiceMail application more as it is intended, not with the s option. In that case, I cannot simply play my own beep beforehand, but rely on the built in one, which I have overwritten. This is to say, you either have to provide your own beep files all the time or can't use custom beep files at all. For most people, I agree this will be a minor issue, if one at all, but it is such a simple issue to fix that it makes no sense for this drawback to persist.
> To rectify this issue, I would propose either:
> - modifying the s option to suppress the beep, because you can manually play a beep in the dialplan beforehand if you want to. The downside is this is not backwards-compatible with existing behavior. I don't seriously believe this option would be considered.
> - adding an additional option which, in addition to the s option, perhaps, would suppress the built in beep. That way, once can truly "silently" go into the voicemail application, and this option can be used when desired. For instance, a "q" option, for true silent/quiet operation.
> I believe an additional quiet option is warranted in this case; I could patch the application code to not play the beep, but the beep would be desirable some of the time, so an option to selectively disable this would be very useful. This grants administrators much more flexibility in voicemail configuration and would make voicemail in the dialplan less clumsy.



--
This message was sent by Atlassian JIRA
(v6.2#6252)