[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