Summary:ASTERISK-19981: Dial plan variables are limited to 4K (4096 bytes)
Reporter:Steven Wheeler (swheeler)Labels:
Date Opened:2012-06-11 14:58:19Date Closed:2012-06-19 08:00:43
Versions: Frequency of
Environment:Asterisk on CentOS 2.7Attachments:
Description:We have a client which is trying to page 150+ users.  When we are building the list of local channels to page we notice that the list is being truncated at 4096 characters (or about 120 users).  I have done a little research and it appears that this value is set in main/pbx.c with this line:
#define VAR_BUF_SIZE 4096.

Question 1: Is it possible to get around this issue without modifying the source code?  We prefer to leave the source alone as it makes transitions between versions much easier.

Question 2: Are there any plans to change this default value or better yet to make it unlimited?

Question 3: If we increase this value to 8192 are we likely to run into issues elsewhere (buffer overflow for example)?
Comments:By: Steven Wheeler (swheeler) 2012-06-11 15:02:08.264-0500

If it helps, this is the dial plan which generates the paging list:

exten => s,n,While($[${i}<${COUNT_USERS(${company})}])
 exten => s,n,Set(HASH(user_info)=${USERS(${company},${i})})
 exten => s,n,Set(pagelist=${pagelist}&Local/${HASH(user_info,username)}@calling/n)
 exten => s,n,Set(i=$[${i}+1])
exten => s,n,EndWhile
exten => s,n,Page(${pagelist:1})

By: Matt Jordan (mjordan) 2012-06-19 08:00:36.148-0500

Answering your questions:

1) No, and I understand your reluctance to modify the source.  If you're tied to your particular approach in the dialplan, however, that may be your only option.

2) Not currently.  Very few people hit this limitation, and most people who do hit this limitation have other ways of accomplishing what they're attempting to do.

3) Unknown, but you're more then welcome to try.

There may be ways of working around this issue with a different dialplan configuration, but the best place to discuss that will be on the asterisk-users mailing list or on the #asterisk IRC channel.

Because this is not a bug but rather a limitation of the current design, I'm going to close this issue as a feature request.  If someone would like to provide a patch that modifies the current behavior, we can reopen this issue as an improvement.  Please contact a bug marshal in #asterisk-bugs in that case.