Summary:	ASTERISK-07198: Voicemail box scanning causes significant and unnecessary i/o activity
Reporter:	Bob Atkins (bob)	Labels:
Date Opened:	2006-06-17 18:13:07	Date Closed:	2011-06-07 14:07:21
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) ast-truss.txt ( 1) ast-truss2.txt
Description:	Asterisk seems to spend its idle time rapidly scanning voicemail boxes. Basically it seems to spend its time opening each box and closing it. Most likely to check status and decide whether a voice mail indication (MWI) is necessary. This creates a significant amount of unnecssary i/o and is particularly noticable when voicemail boxes are in nfs mounted directories. For those of us that are looking to scale into the thousands of users this represents a considerable amount of system load without any good reason. ****** ADDITIONAL INFORMATION ****** I suggest that voicemail boxes need only be scanned when a phone registers, makes or receives a call or renews registration with the system. MWI Notices can be generated when voicemail is left and each time a phone renews its registration and/or makes or receives a call. Perhaps an even simpler approach would be to scan at some configurable interval.
Comments:	By: Tilghman Lesher (tilghman) 2006-06-18 01:27:53 While we could keep an internal count of each mailbox, the problem is that we have external programs, such as vmail.cgi, which could delete voicemail.  Given that we typically need an accurate count, there isn't very much we can do about this. Please note that we do NOT actively scan the mailboxes when idle.  Those scans only occur as a direct result of something (usually a SIP channel) requesting the count.  If you turn subscribemwi=yes in the SIP peer, this scanning of mailboxes should cease, except for SIP peers which directly subscribe to a particular mailbox. By: Bob Atkins (bob) 2006-06-18 03:51:33 Respectfully, it definitely appears that Asterisk is rapidly scanning all voicemail boxes for *all* defined peers that have a mailbox=xxx defined whether or not the device is even registered or talking to Asterisk. I have uploaded a truss output from our system that clearly shows this activity. I can also see it in the NFS network traffic because we happen to have all of the config directories nfs mounted. This is actually what got my attention in the first place. I can confirm that there is no SIP activity that corresponds to the checking of the various voicemail boxes. I can understand needing to check them once in a while - but it seems that they are being checked almost continuously. This process must be hampering the ability of asterisk to handle high volumes of SIP events (call processing) and most likely is impacting RTP stream processing as well and leading to call quality issues on some slower systems. I cannot find any information on exactly what the subscribemwi=yes parameter does or requires from an end user device provisioning standpoint. I can only guess that it will require that the end user device will have to be configrued to specifically subscribe for the MWI message? We are using Polycom, Cisco and Hitachi wireless phones and it would be helpful to know what, if any provisioning changes we would need to make. By: Bob Atkins (bob) 2006-06-18 04:11:50 A quick test of adding subscribemwi=yes to all sip peers that have mailboxes defined did not change the scanning of voicemail boxes. I have uploaded another truss log (ast-truss2.txt) that was captured over a 20 second period that shows all mailboxes being checked - including those that do not have any registrations because the extension phone equipment is not online. I can confirm that the SIP traffic from each extension is almost completely quiet. We have phone re-registrations set to a fairly long interval. While I'm thinking about it. The Polycom phones seem to get new MWI notices from Asterisk on a fairly regular basis - every 15-20 minutes it seems. Each time a notice is received the phone's MWI tone goes off. This 'feature' is kind of annoying as it will continue until the VM has been cleared. Of course I do realize that we are supposed to check our VM when the light is one ;-) By: Tilghman Lesher (tilghman) 2006-06-18 11:33:01 Moved to the SIP project, as the scanning is called from there -- app_voicemail itself, while providing the API for scanning mailboxes, is not directly responsible for this activity. By: Olle Johansson (oej) 2006-06-19 02:36:49 This is a design issue that is better discussed on the mailing list than in the bug tracker. This is the current way of doing it, which is known by almost everyone to be bad, as is most of the voicemail system. A fix would involve all channels and the design of the voicemail system. By: BJ Weschke (bweschke) 2006-06-21 22:51:07 Suspending this. It's more a feature request than it is a bug. We definitely need to address at some point, but this will require a number of core design and code changes and probably won't be tied just to this bug.