Summary:ASTERISK-06879: [patch] 4 bugs in voicemail
Reporter:Bartosz Supczinski (supczinskib)Labels:
Date Opened:2006-05-01 17:55:27Date Closed:2006-05-05 15:45:21
Versions:Frequency of
Environment:Attachments:( 0) app_dial.c_050406.patch
( 1) app_dial.c.patch
( 2) app_voicemail.c_050206.patch
( 3) app_voicemail.c_050406.patch
( 4) app_voicemail.c.patch
( 5) app.c_050406.patch
( 6) app.c.patch
( 7) app.h_050406.patch
( 8) app.h.patch
( 9) bug7064.patch
(10) bug7064-branch12.patch
(11) bug7064-branch12-2.patch
(12) bug7064-branch12-3.patch
(13) bug7064-trunk.patch
(14) bug7064-trunk-upgrade.patch
Description:I`ve found and fixed 4 bugs in voice mail:

* The second improvement is proper playing the message header in voice mail (%vm-tohearenv.gsm%press 3 to hear the message envelope). The bug occurred with playing message every time just after the header.

* Despite the fact that in 'voicemail.conf' an operator vairable was set to 'no' the option operator '0' was active when recording a message.

* Although in 'extension.conf' there was no 'exten => o', there was an attempt to transfer a connection to an unexisting extension when recording a message and pressing '0' and then accepting or canceling the recording

* I`ve fixed a bug, which has occured when changing password to a voice mail from the telephone level. A change of password caused adding an empty line to "voicemail.conf". The error occured only when the 2 last lines of the file were empty. When there was only 1 empty line there was an added username from the previous line.

Yours sincerely
Bartosz Supczinski
IT Specialist

Konstytucji 3 Maja 2
86-300 Grudziadz

t.: +48 (56) 6440100
f.: +48 (56) 6440111
m.: +48 (504) 019040
Comments:By: Leif Madsen (lmadsen) 2006-05-01 19:02:44

Just a quick question -- what do I have to do to reproduce the first bug you mentioned?

By: Bartosz Supczinski (supczinskib) 2006-05-01 19:08:50

Go into your voicemail, choose messages to play '1', tnen for example the first, next choos advanced options '3' and message header '3', after the message header there is the message.

According to your suggestion I`ve separated these fixes from the patch, which give support for Polish language in voicemail.


By: Leif Madsen (lmadsen) 2006-05-01 19:59:50

I can confirm all these issues exist in

supczinskib can you confirm that app_voicemail does not play the %vm-tohearenv.gsm%press 3 to hear the message envelope message if you enter voicemail directly, then hit '3' for advanced options. I only hear option 5, and option 3 (message header) is not announced at all.

By: BJ Weschke (bweschke) 2006-05-01 20:43:51

There's got to be a better way to handle this rather than changing core function params isn't there? :-/

By: Bartosz Supczinski (supczinskib) 2006-05-01 20:57:46

blitzrage: To hear "press 3 to hear the message envelope" there has to be a message in the voicemail and before you enter advanced options you have to play it.

By: Bartosz Supczinski (supczinskib) 2006-05-01 21:05:36

bweschke: At the moment I don`t have any better idea, I know that it may not be the happiest one, but it`s the only way not to break recording. Another may be breaking recording and playing "I`m sorry" message and ending call or starting to record all over again.

By: Leif Madsen (lmadsen) 2006-05-01 21:30:12

supczinskib: yah, but if you go into '3' advanced options right away, you can just hit 3 to play the message headers of any messages in your mailbox -- it works, so I'm wondering if either you shouldn't be able to do that, or it should play the prompt to let the users know you can listen to the headers from that menu directly (instead of needing to play the message first).

By: Leif Madsen (lmadsen) 2006-05-01 21:58:27

I am able to confirm that this patch does indeed fix the first 3 problems (the system I patched uses a DB for the voicemail, so I couldn't verify the last bug was fixed with the patches).

By: Bartosz Supczinski (supczinskib) 2006-05-01 22:03:04

blitzrage: I repaired this mistake.

By: BJ Weschke (bweschke) 2006-05-03 09:27:26

supczinskib: you're quite right. There isn't another way to handle this other than adding another param to the ast_play_and_record function. However, let's take this a step further. Rather than just opting to include/exclude 0 as a term character for recording, how about accepting a string of valid dtmf characters that can terminate the recording? That way, this architectural change has use beyond just the fix that we do need to make. Thanks.

By: Bartosz Supczinski (supczinskib) 2006-05-04 19:19:52

bweschke: Good idea. I already correct it.

By: Jeffrey C. Ollie (jcollie) 2006-05-05 08:39:35

If we're going to change ast_play_and_record, why not make it a bit more generic by allowing separate strings of DTMF digits that will end/accept the message and cancel the message.  I've attached a patch that demonstrates...

By: Serge Vecher (serge-v) 2006-05-05 09:49:37

changing status to 'new' until we have a final patch everybody agrees on.

By: BJ Weschke (bweschke) 2006-05-05 12:36:56

jcollie and supczinskib: both patches submitting are not applying to the present /trunk. Can you please rework them and I'll try to get this in? jcollie - I like your suggestion. You'll both get karma for your work on this! :)

By: Jeffrey C. Ollie (jcollie) 2006-05-05 14:07:59

OK, I've uploaded two patches - one for trunk and one for 1.2.  I think that I have redone the 1.2 branch in a way that won't change the 1.2 API, just adds to it.  The trunk patch even has some doxygen documentation!

By: Russell Bryant (russell) 2006-05-05 14:18:09

I think the default canceldtmf string should be "0".  That way, the only change in behavior being introduced is for app_voicemail, in the case that the operator is not enabled.

By: Jeffrey C. Ollie (jcollie) 2006-05-05 14:49:22

New patch for 1.2 branch that keeps '0' as a cancel digit uploaded...

By: Jeffrey C. Ollie (jcollie) 2006-05-05 15:05:01

Patch for trunk/UPGRADE.txt uploaded...

By: BJ Weschke (bweschke) 2006-05-05 15:45:20

Thanks everyone!!! committed to /trunk and 1.2!