Ticket #5870 (closed Bugs: invalid)

Opened 1 year ago

Last modified 1 year ago

Voicemail bug: Cannot interrupt "Mailbox prompt" with dtmf after a login failure using *97

Reported by: AdHominem Assigned to:
Priority: minor Milestone: 2.11
Component: Voicemail Version: 2.9-branch
Keywords: voicemail login failure prompt Cc:
Confirmation: Need Feedback Distro:
Backend Engine: All Distro Ver:
Backend Ver: SVN Revision (if applicable):

Description

FreePBX and Asterisk allow users to establish a voicemail box.

When you call in to check your voicemail box using *97, you are prompted for a mailbox number and a password. Both of these prompts can be interrupted by dialing. In other words, while you hear the words prompting you for your mailbox # or your password, you can begin dialing. If you do so, the prompt will stop, and the system will accept your input and process it.

However, if your initial login fails, then Asterisk will play 'vm-incorrect-mailbox.ulaw' which is a file that indicates that your login is incorrect, has a pause, and then repeats the request for your mailbox number.

For some reason, this particular prompt is played in such a way that it is NOT interruptable. If you attempt to dial your mailbox number at any time before this prompt ends, the system will not stop playing the prompt and will not process your input. What usually seems to happen, with me at least, is that I start dialing my mailbox number just short of the end of the prompt, and so the system hears the last digit of my mailbox # and the pound key, but not the first digit. As a result, it again finds my login incorrect.

So, the bug is that when FreePBX/Asterisk plays 'vm-incorrect-mailbox.ulaw' after a login failure, it is played in such a way that the prompt cannot be interrupted.

It seems to me that the correct way to process a login failure on a *97 would be to play 'vm-incorrect.ulaw' in a way that is not interruptable, to pause, and then to play 'vm-login.ulaw' in a way that is interruptable.

Change History

06/06/12 11:19:59 changed by p_lindheimer

We use a combination of dialplan to request the mailbox (when using *98 or if not calling in from an extension) and the voicemail application. This is done so that if you enter an incorrect mailbox it does not tell you that (for security) it just asks for the password as normal. Of course if you call in from your extension with *97 it will not prompt you for the mailbox.

In reviewing the dialpan FreePBX adds it looks like none of it should be blocking. (no use of Playback which would cause the described behavior). There are some "Wait()" instructions which can sometimes lead to "stumbling" though it does not sound like that is the issue.

So all and all this looks like it is working as expected (worksforme) but I'll leave the ticket open if you want to provide a trace of your issue in case it exposes some issue not detected in reviewing the dialplan for this.

06/12/12 04:02:20 changed by AdHominem

Okay, I see why it worked for you. You tried it using *98.

Try using *97 from an extension that does not have a mailbox. The error I described occurs only in that scenario.

06/12/12 04:13:45 changed by AdHominem

Here's some relevant logfiles:

[2012-06-12 01:12:05] VERBOSE[20487] file.c: -- <SIP/401-00000240> Playing 'vm-login.ulaw' (language 'en')

[2012-06-12 01:12:09] VERBOSE[20487] file.c: -- <SIP/401-00000240> Playing 'vm-password.ulaw' (language 'en')

[2012-06-12 01:12:10] VERBOSE[20487] app_voicemail.c: -- Incorrect password '66' for user '66' (context = default)

[2012-06-12 01:12:10] VERBOSE[20487] file.c: -- <SIP/401-00000240> Playing 'vm-incorrect-mailbox.ulaw' (language 'en')

[2012-06-12 01:12:14] VERBOSE[20487] file.c: -- <SIP/401-00000240> Playing 'vm-password.ulaw' (language 'en')

[2012-06-12 01:12:16] VERBOSE[20487] app_voicemail.c: -- Incorrect password '66' for user '66' (context = default)

[2012-06-12 01:12:16] VERBOSE[20487] file.c: -- <SIP/401-00000240> Playing 'vm-incorrect-mailbox.ulaw' (language 'en')

06/12/12 04:15:02 changed by AdHominem

And again, it seems to be me that the best way to present this would be to to play 'vm-incorrect.ulaw' in a way that is not interruptable, to pause, and then to play 'vm-login.ulaw' in a way that is interruptable.

06/12/12 09:26:33 changed by p_lindheimer

  • confirmation changed from Unreviewed to Need Feedback.

The log trace seems to confirm the issue is within the Voicemail application which is Asterisk and not easily controlled by us, but I need a CLI trace vs. a log file trace to confirm. (but the fact that it's app_voicemail.c in the above trace pretty much indicates all of that is happening in the voicemail application in Asterisk.

06/12/12 12:02:26 changed by AdHominem

Here's a CLI Trace with Verbosity set to 10.

-- Executing [*97@from-internal:7] VoiceMailMain?("SIP/401-000002cd", "") in new stack

-- <SIP/401-000002cd> Playing 'vm-login.ulaw' (language 'en') -- <SIP/401-000002cd> Playing 'vm-password.ulaw' (language 'en') -- Incorrect password 'xxxxx' for user '40' (context = default) -- <SIP/401-000002cd> Playing 'vm-incorrect-mailbox.ulaw' (language 'en')

Even assuming that this is being handled by Asterisk, I assume that it is possible for FreePBX to do this instead. So, even if this is an Asterisk bug, it is still possible for FreePBX to "fix" it. In fact, I think you've done that quite often in other cases.

06/12/12 12:48:06 changed by p_lindheimer

  • status changed from new to closed.
  • resolution set to invalid.

We fix things where we can or where it makes sense. This one does not seem to fit that category. There is not an easy way get the VM password into the dialplan outside of parsing the voicemail.conf file from an AGI script and then handling it in the dialplan and entering the voicemail without a password.

Given that, at best this is a feature request but it is not a FreePBX bug. If there were an equivalent function to MAILBOX_EXISTS() that we use in the dialplan for our added security, then I would agree we should move this to dialplan to make the experience better. However, there is not such a function that I am aware of.

06/12/12 12:51:30 changed by AdHominem

Fair enough. Thank you for your time. :)