[asterisk-bugs] [JIRA] (ASTERISK-29391) VoiceMail does not cancel recording on rerecord hangup

[Friendly Automation (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-29391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Friendly Automation closed ASTERISK-29391.
------------------------------------------

    Resolution: Fixed

> 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: Unassigned
>         Attachments: debug.txt
>
>
> 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)