Summary:	ASTERISK-10615: [patch] Empty voicemail message file causes call into voicemail to disconnect
Reporter:	dtyoo (dtyoo)	Labels:
Date Opened:	2007-10-24 20:44:42	Date Closed:	2007-11-24 00:24:39.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_voicemail
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 20071025__bug11083.diff.txt ( 1) 20071123__bug11083.diff.txt ( 2) corrupt-vm.patch ( 3) msg0000.wav
Description:	After upgrading from 1.4.9 to 1.4.13 we are having the following problem with voicemail.  We sometimes get voicemail messages left in mailboxes where the wav / data file is 44 bytes long.  The file basically has a header but no data.  Under 1.4.13 calls into voicemail will be disconnected after listening to such a message.  1.4.9 did not have this issue. In case you are curious, these 44 byte messages are being left despite minmessage being set to 3 in the general section of voicemail.conf.  These messages are accompanied by a console message "app.c: No audio available on SIP/IP ADDRESS-b50d7b38??" Nothing special in the console / log file.  Looks the same as when a caller hangs up normally even though in this case they are being disconnected. ****** ADDITIONAL INFORMATION ****** Dell 1950, 2 x 3GHz CPU, 2GB RAM, CentOS 4.4
Comments:	By: Tilghman Lesher (tilghman) 2007-10-25 15:10:34 This patch should take care of it.  Patch and report back your results, please. By: dtyoo (dtyoo) 2007-10-25 22:14:46 Corydon- Testing the patch -- I'm still getting disconnected after listening to one of these empty messages.  I'll upload an example wav file in case anyone else wants to test. By: Tilghman Lesher (tilghman) 2007-10-26 08:24:39 dtyoo:  it's not supposed to prevent you getting disconnected; it's supposed to prevent those empty messages from getting created in the first place.  You'll need to delete all empty messages that currently exist on the system. By: dtyoo (dtyoo) 2007-10-26 08:59:34 OK - I understand.  This will be a little more difficult to test then, as the issue which creates the 44 byte wav files only happens on our production servers under load and is not re-producible in my dev environment.  I will schedule this patch to be included in our next software update.  I did try normal voicemail scenarios, and it doesn't seem to break anything. Will post back results when I have them. By: Tilghman Lesher (tilghman) 2007-10-26 09:14:53 The issue, specifically, is that RTP is not flowing to the voicemail server for whatever reason, but recording was previously using the amount of time which has passed as the indication of the duration, rather than using the number of samples which have been recorded in the file.  Hence, the call may have lasted 30 seconds, but since you received no audio data in that time, the recorded file contained no audio.  This is why the minmessage setting failed to work correctly. By: jharragi (jharragi) 2007-11-16 08:51:11.000-0600 I also experienced something that may be related (on 1.4.13). A voice-mail-user's directory only had greet.* (gsm, wav and WAV) files (and subdirectories). As soon as a call came to this user's vm it was disconnected. The normal behavior if no message was recorded is Alison's message of vm-isunavail plays - this is what is not happening in this case (but not in all accounts with no unavail files). I re-recorded greet.* unavail.* and busy.* and then was not able to reproduce the problem (by having only greet.*). I thought this may be a permissions issue but that shouldn't be the case as the new files are root:root too. But maybe the voice greetings are getting currupted somehow. dtyoo, what happens if you delete the vm account folder that you are experiencing trouble with and let asterisk re-create it? By: dtyoo (dtyoo) 2007-11-16 10:37:02.000-0600 jharragi- The issue we are having is definitely reproducible with any file that is empty / 44 bytes.  We've only been seeing it happen to msgxxx.wav files, but I bet you would get the same behavior if a greeting file was similarly empty. Right now we have a workaround that looks in /var/spool/asterisk/voicemail and copies in a hangup wav file any time it finds a 44 byte wav file. I've scheduled this patch to go onto one of our production servers with the next software update we are rolling out so I can report back some results.  I can't get this issue to happen in our dev environment which makes it a little difficult to test. By: gkloepfer (gkloepfer) 2007-11-19 22:10:07.000-0600 I am also experiencing this bug (1.4 SVN 89397  18-Nov-2007).  However, mine are simply from not setting minmessage to some non-zero value. My concern is that since there already are zero-length voicemail messages recorded, users will start to report problems when the voicemail system simply hangs-up when it encounters one of these messages.  Would there be any value in handling the empty voicemail message condition more gracefully?  I would be happy to help look into this if others feel this kind of fix is needed. (apologies to those monitoring this bug -- I haven't participated in a bug report in a while and got a little quick on the "add note" button) By: dtyoo (dtyoo) 2007-11-20 08:01:45.000-0600 gkloepfer- I think there would definitely be value in looking at the playback routine to see if it can be made to handle the empty file condition more gracefully.  Corydon76's patch should fix one scenario where these empty files are being created, but as is evident from jharragi's note, there is this and possibly other ways that empty files are being created.  Its unclear to me that Corydon76's patch will fix all possible scenarios where files are being created (Corydon76 - can you comment on this?).   These empty files definitely did not disconnect callers under 1.4.9 so something must have changed in the playback routine between 1.4.9 and 1.4.13.  I would be happy to test anything you come up with. By: gkloepfer (gkloepfer) 2007-11-23 11:17:05.000-0600 I have submitted a patch for app_voicemail.c that handles corrupt or empty voicemail messages and more gracefully deals with the issue.  I didn't realize that I needed to resubmit a "disclaimer" so the patch is not yet available. Basically the fix assumes that, in play_message(), if the file being played-back gets a negative (error) return from wait_file() (which is really just a call to the Asterisk streaming playback API) the error is from a corrupt or missing file.  Therefore the error is ignored and control is returned as though the message played-back in its entirety and the caller did not press any DTMF digit. An error message like: [Nov 23 10:54:28] WARNING[28595]: app_voicemail.c:4621 play_message: Playback of voicemail message /var/spool/asterisk/voicemail/default/200/INBOX/msg0000 failed (-1). is also logged so that, if the error is due to something more critical, that there is some indication that it is actually happening. I normally would not recommend simply ignoring the error return like this, but there is not a good way to inform the caller that there's a problem, and simply bailing-out of the voicemail system entirely is not a helpful action. Of course, it is still a good idea to not create the corrupt VM files to begin with... (so minmessage=1 and any other fixes to prevent this condition are also needed). By: Tilghman Lesher (tilghman) 2007-11-23 13:32:51.000-0600 gkloepfer: something along these lines?  I can't see your patch, either, yet. By: gkloepfer (gkloepfer) 2007-11-24 00:04:40.000-0600 No, that's not exactly it.  You want to keep res as the return value from wait_file, check to see if res < 0, and if it is, display the error and set res = 0.  The return values >= 0 from wait_file are important to pass along to the routine that calls play_message. <OT> I'm hoping that my "license" is approved pretty quickly.  I understand the need for the disclaimer to assure that the code remains untainted, but I figured that the paper one I signed about 2 years ago would carry-over...  Argh.  This legal stuff is ridiculous... </OT> By: Digium Subversion (svnbot) 2007-11-24 00:17:00.000-0600 Repository: asterisk Revision: 89540 U   branches/1.4/apps/app_voicemail.c U   branches/1.4/main/app.c ------------------------------------------------------------------------ r89540 | tilghman | 2007-11-24 00:16:58 -0600 (Sat, 24 Nov 2007) | 9 lines Currently, zero-length voicemail messages cause a hangup in VoicemailMain. This change fixes the problem, with a multi-faceted approach.  First, we do our best to avoid these messages from being created in the first place, and second, if that fails, we detect when the voicemail message is zero-length and avoid exiting at that point. Reported by: dtyoo Patch by: gkloepfer,tilghman (Closes issue ASTERISK-10615) ------------------------------------------------------------------------ By: Digium Subversion (svnbot) 2007-11-24 00:22:20.000-0600 Repository: asterisk Revision: 89541 _U  trunk/ U   trunk/apps/app_voicemail.c U   trunk/main/app.c ------------------------------------------------------------------------ r89541 | tilghman | 2007-11-24 00:22:19 -0600 (Sat, 24 Nov 2007) | 17 lines Merged revisions 89540 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r89540 | tilghman | 2007-11-24 00:19:23 -0600 (Sat, 24 Nov 2007) | 9 lines Currently, zero-length voicemail messages cause a hangup in VoicemailMain. This change fixes the problem, with a multi-faceted approach.  First, we do our best to avoid these messages from being created in the first place, and second, if that fails, we detect when the voicemail message is zero-length and avoid exiting at that point. Reported by: dtyoo Patch by: gkloepfer,tilghman (Closes issue ASTERISK-10615) ........ ------------------------------------------------------------------------ By: Tilghman Lesher (tilghman) 2007-11-24 00:24:39.000-0600 gkloepfer: your license will probably be approved sometime on Monday.  Note that the disclaimer is, in fact, gone, and that this is just a license agreement (although it's also been updated from the original license agreement).