Summary:	ASTERISK-06537: [patch] Race condition? User leaves voicemail, SIP phone notifies desk user of message, user checks, message blank
Reporter:	Sebastian Torf (storf)	Labels:
Date Opened:	2006-03-13 14:01:03.000-0600	Date Closed:	2008-01-15 17:35:25.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_voicemail
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 20060317__bug6714.diff.txt
Description:	Incoming call gets diverted to voicemail. Incoming caller leaves voice mail. SIP phone (Cisco 794x) alerts recipient of a new message. Incoming caller has not finished leaving the voicemail yet. Recipient checks new messages, but Asterisk neither knows the timestamp nor the length of the message yet, because it is still  being recorded. Recipient deletes message while incoming caller has not finished leaving his message yet and exits the voicemail menu. Incoming caller then finishes the message and hangs up as well, but recipient never receives this message, because it has already been erroneously deleted. ****** ADDITIONAL INFORMATION ****** Race condition? Intended result would be for Asterisk to notify the Cisco SIP phone _after_ the message has been completely received (very much the same way that the e-mail application sends out the message _after_ it is completely available). Notifying the SIP device _after_ the message has finished recording is one solution, but it does not prevent an overly eager phone user to check the voicemail while someone else is leaving one still for him/her. Ultimately, the voicemail application should not state that there is a new message unless that message was completely processed.
Comments:	By: Jared Smith (jsmith) 2006-03-13 15:24:24.000-0600 For what it's worth, I've heard of several people in the community having this same problem, but nobody can seem to reproduce it.  Can you please test with Asterisk 1.2.5, and try to reproduce? By: Leif Madsen (lmadsen) 2006-03-13 15:43:09.000-0600 I've heard of this too from someone at Williams Communications -- there was talk of trying to get them to sponsor the development to have this fixed, but never came to fruition -- but I had independently heard of this same problem. I haven't verified myself though. By: alric (alric) 2006-03-14 13:49:53.000-0600 Just duplicated this myself, with release 1.2.5.  I have a Polycom IP 601 setup with one line occurace registered, with a mailbox entry in sip.conf.  A call comes in, I reject it.  As soon as it begins writing the VM files, the MWI light lights up.  From what I've seen so far, this is 100% reproducable. What kind of debugs will be needed to work on this?  SIP debug with the NOTIFY messages? By: Olle Johansson (oej) 2006-03-14 14:40:25.000-0600 The SIP MWI checking and turning on the lamp is on a separate clock and is not in any way triggered by someone actually leaving the voicemail. I guess the problem is the code that checks if there's a new voicemail - it is run during the recording and see one file that is open but doesn't react to the lock. If the lock is in the directory, it should propably remove one message from the count. I can easily see how this happens from the code. It should be pretty easy to fix. By: Sebastian Torf (storf) 2006-03-14 15:19:33.000-0600 Thanks to Alric for confirming this. I would have had trouble upgrading our production site on short notice. Thanks to oej for the insight into the SIP notification mechanism and a potential fix. However, once the SIP notification mechanism gets fixed or looked at, it still does not address the issue where a VM user can potentially check messages as they are recorded. Could a file "lock" also be implemented for the VM application such that it does not allow VM users to browse through messages that are _currently_ in the process of recording? I think that would address all issues listed here. There may, however, be other processes that also sync with the VM application in a similar manner (Cisco's Skinny protocol, IAX, etc.) By: alric (alric) 2006-03-14 15:30:02.000-0600 What about recording in an alternative directory, and moving that recording in after its finished?  Although I suppose that could break things under some obscure situation. By: Olle Johansson (oej) 2006-03-14 15:54:14.000-0600 It's not a SIP problem at all, it concerns all channels. It's in the voicemail system this has to be fixed so that a voicemail that is being recorded and is not done, never counts in calculating the number of mails. because another issue is that if the recording is silent, it may be deleted and will never show up at all, so the notification is wrong. By: Olle Johansson (oej) 2006-03-14 15:55:28.000-0600 Alric: The whole system needs a rewrite. Feel free to start any time, I will certainly support it. But while waiting for that, let's check if there's a short time ugly and dirty fix that can remove this race condition! /O ;-) By: Tilghman Lesher (tilghman) 2006-03-17 11:00:03.000-0600 This patch should take care of it.  Please download, apply, compile, install, and test. By: Olle Johansson (oej) 2006-03-18 03:16:05.000-0600 Thanks for looking into this, Corydon! Seems like a simple and working beautiful fix :-) By: Olle Johansson (oej) 2006-03-18 03:58:40.000-0600 Applied to test-this-branch. Please test. By: Tilghman Lesher (tilghman) 2006-03-21 00:27:15.000-0600 Committed to 1.2, merged to trunk By: Digium Subversion (svnbot) 2008-01-15 17:35:25.000-0600 Repository: asterisk Revision: 13388 U   team/oej/test-this-branch/README.test-this-branch U   team/oej/test-this-branch/apps/app_voicemail.c ------------------------------------------------------------------------ r13388 | oej | 2008-01-15 17:35:24 -0600 (Tue, 15 Jan 2008) | 2 lines Fix race in voicemail (corydon76, ASTERISK-6537) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=13388