[asterisk-bugs] [JIRA] (ASTERISK-29391) VoiceMail does not cancel recording on rerecord hangup
N A (JIRA)
noreply at issues.asterisk.org
Tue Apr 13 16:52:58 CDT 2021
[ https://issues.asterisk.org/jira/browse/ASTERISK-29391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=254523#comment-254523 ]
N A commented on ASTERISK-29391:
--------------------------------
Here is everything from my voicemail.conf except the mailboxes and any commented lines. Keeping mind the conf files is from when I first installed Asterisk on 13.something and I've just been copying it over since.
[general]
format = wav49|wav
serveremail = centrex at voip.phreaknet.org
attach = yes
skipms = 3000
silencethreshold = 128
maxlogins = 3
moveheard=yes
fromstring=CENTREX Voicemail
emailsubject=[Voicemail]: New message ${VM_MSGNUM} in mailbox ${VM_MAILBOX}
emailbody=Dear ${VM_NAME},\n\tYou were just left a ${VM_DUR} long message (number ${VM_MSGNUM}) in mailbox ${VM_MAILBOX} from ${VM_CALLERID}, on ${VM_DATE}.\n\n\t--Your CENTREX Voicemail System\n
pagerfromstring=CENTREX Voicemail
pagersubject=New VM
pagerbody=New ${VM_DUR} long msg in box ${VM_MAILBOX} from ${VM_CALLERID}, on ${VM_DATE}
emaildateformat = %A, %B %d, %Y at %r
pagerdateformat = %A, %B %d, %Y at %r
saydurationm=2 ; Specify the minimum duration to say. Default is 2 minutes
sendvoicemail = yes ; Allow the user to compose and send a voicemail while inside VoiceMailMain() [option 5 from mailbox's advanced menu]. If set to 'no', option 5 will not be listed.
review=yes ; Allow sender to review/rerecord their message before saving it [OFF by default
minpassword = 4 ; Enforce minimum password length
[zonemessages]
pacific = America/Los_Angeles|'vm-received' Q 'digits/at' IMp
mountain = America/Denver|'vm-received' Q 'digits/at' IMp
eastern = America/New_York|'vm-received' Q 'digits/at' IMp
central = America/Chicago|'vm-received' Q 'digits/at' IMp
central24 = America/Chicago|'vm-received' q 'digits/at' H N 'hours'
military = Zulu|'vm-received' q 'digits/at' H N 'hours' 'phonetic/z_p'
european = Europe/Copenhagen|'vm-received' a d b 'digits/at' HM
[default]
The actual mailbox in question looks like this:
1234=> 1234,John Smith,email at example.com,,tz=central|attach=no
> VoiceMail does not cancel recording on rerecord hangup
> ------------------------------------------------------
>
> Key: ASTERISK-29391
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-29391
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Applications/app_voicemail
> Affects Versions: 18.3.0
> Environment: Debian 10
> Reporter: N A
> Assignee: N A
>
> I believe this is a bug, because I can't see how this is intentionally desired behavior:
> If I call into a voicemail box and begin leaving a message, then press #, I get additional options. If I press the option to re-record the message, but I hang up *BEFORE* it starts recording the redo, Asterisk processes this event as if a voicemail was left (when the user was actually trying to back out).
> Asterisk sends an email that begins like this:
> You were just left a 0:00 long message (number 1) in mailbox...
> Additionally, my message waiting lamps come on.
> At the time of hangup, this is in the CLI:
> [2021-04-13 15:28:37] WARNING[7865][C-00000b64]: app.c:1647 __ast_play_and_record: No audio available on Local/..........-000009c4;2??
> [Apr 13 15:28:37] -- User hung up
> When I retrieve the message, or attempt to retrieve it, this happens:
> [Apr 13 15:23:27] -- <SIP/ATAxLA1-0000039f> Playing '/var/spool/asterisk/voicemail/......../INBOX/msg0000.slin' (language 'en')
> [2021-04-13 15:23:27] WARNING[7598][C-00000b60]: app_voicemail.c:8988 play_message: Playback of message /var/spool/asterisk/voicemail/......../INBOX/msg0000 failed
> So there isn't even a 0:00 second message. The message just doesn't exist in the first place. At least, the audio for it doesn't, but all the properties of this message do, so I can delete the message which will get rid of it and then my message waiting lamps turn off.
> The original message is discarded, which is good, but this seems to be undesired behavior, perhaps an edge case not accounted for? I believe Asterisk should be discarding the message if a user hangs up before rerecording starts, but it seems to go through anyways.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list