[asterisk-bugs] [Asterisk 0016271]: [patch] message limit (maxmsg) can be exceeded in 1.6.x creating orphan voicemail

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16271 
====================================================================== 
Reported By:                sohosys
Assigned To:                mnick
====================================================================== 
Project:                    Asterisk
Issue ID:                   16271
Category:                   Applications/app_voicemail
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
JIRA:                       SWP-432 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-11-18 08:27 CST
Last Modified:              2010-01-04 12:22 CST
====================================================================== 
Summary:                    [patch] message limit (maxmsg) can be exceeded in
1.6.x creating orphan voicemail
Description: 
If two are more users are in the process of leaving a voicemail message,
and the count of messages in the mailbox was maxmsg-1 when they started
leaving the message, the application will record all new messages.

Messages will be numbered in the order they were completed, and all
messages over the limit will be inaccessible to the end user. We have
tested up to 5 callers in voicemail resulting in maxmsg+4 messages and 4
inaccessible messages. I assume there is no limit based on the code.

We run some high volume asterisk servers where this has become common. In
the 1.6 series the message is not reported and not accessible by the end
user, although the caller that left the last messages(s) had no indication
of the full mailbox.

I guess this could be classified as minor or major depending on the
content of the messages in the black hole and the job title of the mailbox
owner.

In the 1.2.x series a crash is the result when the end user tries to
access the last messages in the mailbox, and we fixed that by simply adding
10 to our desired maxmsg count in voicemail.conf and changing the code to
test for msgcount <= maxmsg - 10 before accepting a new message, but the
1.6 code is more complex, and our 1.2 solution is too primitive for a
current version, although transparently buffering the variables might be a
good simple solution.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0015117 crash in voicemail when more than maxms...
====================================================================== 

---------------------------------------------------------------------- 
 (0115955) sohosys (reporter) - 2010-01-04 12:22
 https://issues.asterisk.org/view.php?id=16271#c115955 
---------------------------------------------------------------------- 
I strongly disagree. This fix will rarely allow more than the configured
max, as the conditions to duplicate the problem are rare. No commercial
voicemail system will ever allow a caller to record a message and then
"discard it". The “full mailbox” notification is ALWAYS before the
caller is allowed to record anything, discarding or trying to notify the
user after they hang up (which callers do when they are done speaking,
without waiting for additional confirmation) will not work, it will lead
caller to believe they have left a message that was not actually saved,
which will result in miscommunication and potential bad will. Our Asterisk
clusters are configured with 2000 voicemail boxes per cluster, and we have
only ever had a very small number of instances of max messages +1, and
never an instance of max messages +2. Having a hard limit that can be
exceeded only by the number of callers actively leaving a message when the
full condition is reached seems like the only viable option. In other
words, once the system invites the caller to record a message it needs to
be recorded for delivery to the intended recipient, without exception. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-01-04 12:22 sohosys        Note Added: 0115955                          
======================================================================