[asterisk-bugs] [Asterisk 0014739]: [patch] Voicemail(ARGS) is limtted to 1024 characters, large 'blast' groups are silently left off

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14739 
====================================================================== 
Reported By:                p_lindheimer
Assigned To:                tilghman
====================================================================== 
Project:                    Asterisk
Issue ID:                   14739
Category:                   Applications/app_voicemail
Reproducibility:            have not tried
Severity:                   major
Priority:                   normal
Status:                     ready for testing
Target Version:             1.6.3.0
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-03-24 16:53 CDT
Last Modified:              2009-04-17 12:01 CDT
====================================================================== 
Summary:                    [patch] Voicemail(ARGS) is limtted to 1024
characters, large 'blast' groups are silently left off
Description: 
When sending voicemail to several users in the supported format:

Voicemail(200 at default&201 at default& ... 299 at default,s)

the app_voicemail truncates the resulting parameter to 1024 characters. In
FreePBX, there is a blast group that accumulates these into a channel
variable. Therefore, the size that should be allowed should be at least
equivalent to the max size of a channel variable. (Or larger if a command
line can be longer). Unless of course there are other limitations...

In FreePBX, this is called as:

exten => 1,1,VoiceMail(${GRPLIST:1},s)                                    
                                                                        

where the list was previously accumulated in GRPLIST.

The following change reportedly fixes the issue until the new limitation
is met:

--- app_voicemail.c     (revision 184036)
+++ app_voicemail.c     (working copy)
@@ -4962,7 +4962,7 @@
        char fmt[80];
        char *context;
        char ecodes[17] = "#";
-       char tmp[1024] = "";
+       char tmp[2048] = "";
        char *tmpptr;
        struct ast_vm_user *vmu;
        struct ast_vm_user svm;

So it would seem that either a much larger tmp variable should be created
to address very large lists, or it should be dynamically allocated based on
the sizeof the ext argument that is passed to it.

(note - I marked it 'major' because the dialplan is silently corrupting
the data, seemed like it was more than minor, less than major)...
====================================================================== 

---------------------------------------------------------------------- 
 (0103371) p_lindheimer (reporter) - 2009-04-17 12:01
 http://bugs.digium.com/view.php?id=14739#c103371 
---------------------------------------------------------------------- 
If 1024 is "good enough for most people" that would imply that Asterisk is
limited to roughly 75 extensions for an installation that wants the ability
to do voicemail blast groups to all employees. This doesn't do Asterisk
justice as we all know it is MUCH more capable then that. The 1024 is
arbitrary and my understanding is that the suggested patch is not
applicable to the 1.4 branch of Asterisk.

I can understand if there is not an 'elegant' solution for 1.4 as proposed
in the supplied patch. However, bumping this up to a bigger number such as
4096 (or maybe double that) will take this from effecting maybe "1%" of
installations to maybe "0.01%" as it would mask the issue until someone
tried to do over 300 simultaneous extensions.

I would also suggest that as long as the value stays static, it's length
is tested against the static length (currently 1024) and an error is logged
to the log file. As it stands, it results in a silent failure which is
never a good thing... 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-04-17 12:01 p_lindheimer   Note Added: 0103371                          
======================================================================