[Home]

Summary:ASTERISK-05541: Changing fmt=wav49|gsm|wav to fmt=wav49 in voicemail.conf corrupts mailbox
Reporter:bdolljr (bdolljr)Labels:
Date Opened:2005-11-09 18:09:18.000-0600Date Closed:2008-01-15 15:55:25.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_voicemail
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) app_voicemail.c.diff
Description:When changing the fmt=wav49|gsm|wav line in voicemail.conf to fmt=wav49 REALLY bad things happen.

Basically all new voicemails are saved with two files, msgXXXX.txt and msgXXXX.WAV after the change to fmt=wav49.

Prior to the change four files are created, msgXXXX.txt, msgXXXX.gsm, msgXXXX.wav and msgXXXX.WAV.

After the change to fmt=wav49 when a subscriber deletes a message that was recorded prior to the change (with four files) only two of the files get replaced / deleted.  These new files are msgXXXX.txt and msgXXXX.WAV.  The old msgXXXX.gsm and msgXXXX.wav files are still there.

Now when the caller calls in to retrieve messages the playback function plays one of the old files.  Not sure which one...  either msgXXXX.gsm or msgXXXX.wav.  The user thinks they have already deleted that message so they try and delete it again.  What gets deleted is msgXXXX.WAV which wasn't the message they were hearing.  So the number of messages in their mailbox decrements by one and the next time the log in the same message they tried to delete is still there.  This leads the user to believe that the system is deleting the WRONG messages.  When in fact it's deleting the correct message, just playing the wrong message.

So there are three resolutions to this problem:

1) Fix the code so that the delete / rename (resequence) function deletes msgXXXX.* first so that the old message is really gone.  This would solve the problem of recording in fewer formats than message being replaced / delted was recorded in.

2) Fix the playback code to play the file which matches the current record format.  This has the drawback that the old (now unsupported) file types will never be deleted and remain in the mailbox folders never to be used.

3) Place a HUGE warning in voicemail.conf that removing formats from the fmt= line REQUIRES the admin to manually delete all the files which are recorded in the now obsolete formats in all the folders in all maiboxes.
Comments:By: Kevin P. Fleming (kpfleming) 2005-11-10 19:20:23.000-0600

I chose option #3, since I don't believe there is any truly reliable way to code around this problem. The warning is now present in CVS HEAD.
By: bdolljr (bdolljr) 2005-11-11 13:55:17.000-0600

I would like to upload a patch that fixes this using option 1.  Thanks.
By: bdolljr (bdolljr) 2005-11-11 13:56:26.000-0600

Uploaded.
By: bdolljr (bdolljr) 2005-11-11 14:33:06.000-0600

To add clarification to the description:

If your mailbox looks like this:

-rw-------  1 root root  18513 Nov 11 11:16 msg0000.gsm
-rw-------  1 root root    258 Nov 11 11:16 msg0000.txt
-rw-------  1 root root 179564 Nov 11 11:16 msg0000.wav
-rw-------  1 root root  18260 Nov 11 11:16 msg0000.WAV
-rw-------  1 root root  11979 Nov 11 11:16 msg0001.gsm
-rw-------  1 root root    257 Nov 11 11:16 msg0001.txt
-rw-------  1 root root 116204 Nov 11 11:16 msg0001.wav
-rw-------  1 root root  11826 Nov 11 11:16 msg0001.WAV
-rw-------  1 root root    257 Nov 11 11:24 msg0002.txt
-rw-------  1 root root  13516 Nov 11 11:24 msg0002.WAV
-rw-------  1 root root    257 Nov 11 11:24 msg0003.txt
-rw-------  1 root root   7016 Nov 11 11:24 msg0003.WAV
-rw-------  1 root root    257 Nov 11 11:24 msg0004.txt
-rw-------  1 root root   9226 Nov 11 11:24 msg0004.WAV
-rw-------  1 root root    257 Nov 11 11:24 msg0005.txt
-rw-------  1 root root   3830 Nov 11 11:24 msg0005.WAV
-rw-------  1 root root    257 Nov 11 11:24 msg0006.txt
-rw-------  1 root root   7016 Nov 11 11:24 msg0006.WAV

...notice the change in format between msg0001 and msg0002... and you login and try to delete msg0001 which is the second message in your mailbox, after you logout your mailbox looks like this:

-rw-------  1 root root  18513 Nov 11 11:16 msg0000.gsm
-rw-------  1 root root    258 Nov 11 11:16 msg0000.txt
-rw-------  1 root root 179564 Nov 11 11:16 msg0000.wav
-rw-------  1 root root  18260 Nov 11 11:16 msg0000.WAV
-rw-------  1 root root  11979 Nov 11 11:16 msg0001.gsm
-rw-------  1 root root    257 Nov 11 11:24 msg0001.txt
-rw-------  1 root root 116204 Nov 11 11:16 msg0001.wav
-rw-------  1 root root  13516 Nov 11 11:24 msg0001.WAV
-rw-------  1 root root    257 Nov 11 11:24 msg0002.txt
-rw-------  1 root root   7016 Nov 11 11:24 msg0002.WAV
-rw-------  1 root root    257 Nov 11 11:24 msg0003.txt
-rw-------  1 root root   9226 Nov 11 11:24 msg0003.WAV
-rw-------  1 root root    257 Nov 11 11:24 msg0004.txt
-rw-------  1 root root   3830 Nov 11 11:24 msg0004.WAV
-rw-------  1 root root    257 Nov 11 11:24 msg0005.txt
-rw-------  1 root root   7016 Nov 11 11:24 msg0005.WAV

... notice that msg0001.wav and msg0001.gsm are still there.  If you try and play msg0001 one of these two files will play.  Not the real msg0001.WAV.  So the user continually tries to delete this message just to lose the real msg0001.WAV.
By: Kevin P. Fleming (kpfleming) 2005-11-11 16:18:16.000-0600

The reason that I chose option #3 is because fixing this properly is quite difficult; for example, what happens if you try to forward a message that was recorded prior to the change, and prepend a message to it? The new content will be recorded in all the new formats, but the old content is not available in all those formats, so the forwarding will fail.

app_voicemail implicitly assumes that if 'fmt' contains four formats, that _every_ message in every folder of every mailbox will be recorded in all those formats, and no others. Auditing every code path to work properly when that assumption is false will take quite some time and effort, and is far too invasive to be addressed prior to the 1.2 release. We certainly can't commit a patch that only partially solves the problem... if you wish to continue working on this problem you are welcome to do so, but the result of that work will be essentially a 'new feature' that teaches app_voicemail how to deal with the results of the change.
By: Digium Subversion (svnbot) 2008-01-15 15:55:25.000-0600

Repository: asterisk
Revision: 7059

U   trunk/ChangeLog
U   trunk/configs/voicemail.conf.sample

------------------------------------------------------------------------
r7059 | kpfleming | 2008-01-15 15:55:25 -0600 (Tue, 15 Jan 2008) | 2 lines

issue ASTERISK-5541

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=7059