VM Blast Group limitation on number of extensions in group

General Help
1

I posted this on the Trixbox forums earlier in the week and have received no response as of yet. I think that the FreePBX forums may be more appropriate so here goes.

I have a system running Trixbox 2.2.12 with FreePBX 2.4. There are many VM Blast groups on the system. There is an “All Company” blast group that contains 101 extensions. When a message is left for this group only the first 79 extensions actually receive the message.

I have gone through the code in extensions_additional.conf and figured out that a channel variable called GRPLIST is created containing a concatenated list of voicemail extensions that is then set in the VoiceMail application to send the message to the list. This particular system is using 4 digit extensions with the voicemail context of “default” for all extensions. Each voicemail extension is concatenated to the GRPLIST in the following format:

&xxxx@default , where xxxx is the extension number. (13 characters long)

Therefore I have calculated that the GRPLIST works when its length is 79x13=1027 characters. I am presupposing that the 80th extension adds another 13 characters to the GRPLIST variable and therefore makes the variable too long and so does not get concatenated to the GRPLIST. The problem is that I cannot find any documentation on the maximum length of a channel variable.

I am posting an example of the context that I am talking about from extensions_additional.conf just in case I have not made myself clear enough.

Here is an example of the GRPLIST being created. You can clearly see the extensions being concatenated. In this example the extensions are only 3 digits in length.

[vmblast-grp]
include => vmblast-grp-custom
exten => 501,1,Macro(user-callerid,)
exten => 501,n,Answer
exten => 501,n,Wait(1)
exten => 501,n,Set(GRPLIST=)
exten => 501,n,Macro(get-vmcontext,210)
exten => 501,n,Set(GRPLIST=${GRPLIST}&210@${VMCONTEXT})
exten => 501,n,Macro(get-vmcontext,220)
exten => 501,n,Set(GRPLIST=${GRPLIST}&220@${VMCONTEXT})
exten => 501,n,Macro(get-vmcontext,231)
exten => 501,n,Set(GRPLIST=${GRPLIST}&231@${VMCONTEXT})
exten => 501,n,Macro(get-vmcontext,234)
exten => 501,n,Set(GRPLIST=${GRPLIST}&234@${VMCONTEXT})
exten => 501,n,Macro(get-vmcontext,246)
exten => 501,n,Set(GRPLIST=${GRPLIST}&246@${VMCONTEXT})
exten => 501,n,Set(DIGITS=501)
exten => 501,n,Goto(app-vmblast,vmblast,digits)
; end of [vmblast-grp]

This next example illustrates how the GRPLIST is set as a parameter for the VoiceMail command.

[app-vmblast]
include => app-vmblast-custom
exten => vmblast,1(digits),ExecIf($["${DIGITS}" != “”],SayDigits,${DIGITS})
exten => vmblast,n(msg),ExecIf($["${MSG}" != “”],Background,${MSG})
exten => vmblast,n,Background(if-correct-press&digits/1)
exten => vmblast,n,WaitExten(20,)
exten => vmblast,n,Playback(sorry-youre-having-problems&goodbye)
exten => vmblast,n,Hangup
exten => 1,1,VoiceMail(${GRPLIST:1},s)
exten => 1,n,Hangup
; end of [app-vmblast]

So…has anyone experienced this issue where the number of voicemail extensions in a VM Blast group is capped at some specific number? If so, have you found a way around this issue? Does anyone know what the maximum length of a channel variable is?

Thanks in advance,
Ron

2

there very well may be such a limitation. Can you add some Noops to it where you think it is starting to fail and then review the CLI/logs to see if that is what is happening by printing out the progression each step at that point? (modify extensions_additional.conf and then do a reload at the CLI)

If you find that is the issue, see if you can create a temporary AstDB variable and use that instead of the GRPLIST channel variable, I believe I tested AstDB variables at one point for length and they were very large.

3

Thanks for the tip. I am still relatively new to the asterisk dialplan customization and commands.

The GRPLIST variable definitely contains all of the voicemail extensions in the blast group. So the issue must be with the VoiceMail command. I will dive into the C code for the VoiceMail application to see if I can find something there.

4

After looking at the app_voicemail.c code, I found the issue. There is a routine called leave_voicemail. In the routine there is a variable declaration

char tmp[1024]

I changed this declaration to

char tmp[2048]

and I recompiled asterisk. I replaced the app_voicemail.so file on a test PBX with the affected customer’s configuration, set the permissions, and tested. All extensions in the “Entire Company” blast group received the test message.

This fix should be good for a blast group with up to 158 extensions on a system that uses 4 digit extensions and the default voicemail context.

5

Sounds like an Asterisk bug:

http://bugs.digium.com/view.php?id=14739

you may want to report it in the FreePBX tracker with a link to the above, so others who run into this will see the issue and we can track to when they fix in in Asterisk.

6

Thanks for reporting this to Digium. I was going to do that but you beat me to the punch. I have checked Asterisk 1.2, 1.4 and 1.6 and it is an issue in the voicemail module in each version.

I wouldn’t necessarily call it a bug, but rather an undocumented maximum setting. No matter what the variable length is set to, I don’t think it could handle every possible scenario due to the way that this feature is implemented.

I will submit a ticket to the FreePBX tracker.

7

it could be handled, you would just have to malloc the memory based on the size of the line being passed. If there is a limitation, it should be in app_voicemail(), it should be in the size of a channel variable or the size of a command line, unless voicemail had a real limitation to the number of boxes that could be blasted and if that were the case, it would still have to parse to see if it hit that number (and then write out an error to the log).

Anyhow - thanks for reporting it and thanks in advance for updating the tracker.

8

There is a limitation in current Asterisk. While there is no limit to channel variables, as defined, the longest that any evaluation of contents may be is 4095 characters. So if all you’re doing is evaluating a variable, the maximum effective length of that variable will be 4095 characters. If you’re evaluating a variable, prefixed by 30 other characters, then the maximum value of that variable within the context of that evaluation will be 4065 (4095 - 30) characters.

BTW, the 1024 byte buffer within app_voicemail is unlikely to be changed in any current version. Starting in 1.6.3, however, the above limit on variable substitution will go away entirely, as will this 1024-byte limitation. This is a part of the str_substitution developer branch.