Summary:	ASTERISK-10896: Option eventwhencalled seems not working properly.
Reporter:	Andrey Solovyev (corruptor)	Labels:
Date Opened:	2007-11-27 07:47:32.000-0600	Date Closed:	2010-06-22 06:36:37
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) events.txt
Description:	I have Queue [1] defined in queues.conf (see additional info) with eventwhencalled=yes option and one member SIP/201. When I call this queue (using macro-dialqueue, see additional info) and listen to the events using manager api i get this event  when SIP/201 us called: Event: AgentCalled Privilege: agent,all AgentCalled: SIP/201 AgentName: 201 ChannelCalling: SIP/204-08bf95a0 CallerID: 204 CallerIDName: 204 Context: macro-dialqueue Extension: s Priority: 12 Variable: SIPUSERAGENT=THOMSON ST2030 hw3 fw1.56 00-0E-50-4E-F5-E4e|1") in new stack new stack new stacknew stackackeid: 1196169296.2|Channel: SIP/204-08bf95a0") in new stack In Asterisk CLI i see error: [Nov 27 16:14:12] ERROR[27795]: pbx.c:5740 pbx_builtin_serialize_variables: Data Buffer Size Exceeded! This error go away if I change macro by deleting line with UserEvent. In this case buffer size is not exceeded. Setting eventwhencalled=vars doesn't change anything. I guess that Variable field should appear only when we set eventwhencalled=vars.   Anyway the formatting is unreadable. Should this be somehow fixed? Thank you. ****** ADDITIONAL INFORMATION ****** queues.conf [1] ; is a "q501" section wrapuptime=0 timeout=10 strategy=ringall retry=1 musiconhold=default monitor-join=yes monitor-format=wav maxlen=0 leavewhenempty=no joinempty=yes announce-holdtime=no ringinuse=no eventwhencalled=yes announce-frequency=30 member=SIP/201,0,201 I dial queue using macro-dialqueue. [internal] exten => 501,1,Macro(dialqueue,1) [macro-dialqueue] ;ARG exten => s,1,Noop(ARG1 - ${ARG1}, ARG2 - ${ARG2}) exten => s,n,Answer() exten => s,n,Set(__QueueUniqueId=${UNIQUEID}) exten => s,n,Set(__TRANSFER_CONTEXT=transfered-context) exten => s,n,Set(__CallType=QUEUEIN) exten => s,n,Set(UNIQUEID1=${CUT(QueueUniqueId,.,1)}) exten => s,n,Set(UNIQUEID2=${CUT(QueueUniqueId,.,2)}) exten => s,n,Set(__QueueMonitorFilename=${UNIQUEID1}-${UNIQUEID2}) exten => s,n,Set(MONITOR_FILENAME=${RECSAVEDIR}/${QueueMonitorFilename}) exten => s,n,UserEvent(QueueIn|QueueName: ${ARG1}|CallerID: ${CALLERID(all)}|Uniqueid: ${UNIQUEID}|Channel: ${CHANNEL}) exten => s,n,Queue(${ARG1}|t|||${ARG2}) exten => s,n,Hangup
Comments:	By: Mark Michelson (mmichelson) 2007-11-27 15:29:28.000-0600 You are correct that you should not be seeing the values of the channel variables in the manager event unless you have specified "vars" for the value of eventwhencalled. I believe I have found the source of this issue. However, it appears as though there is a deeper issue here regarding the manager, but before I start working on it, I need to clarify something. When you got rid of the UserEvent, you said the buffer size was not exceeded. Was the manager output readable in this case, or was it still the string of junk that you showed in the description? By: Digium Subversion (svnbot) 2007-11-27 17:07:33.000-0600 Repository: asterisk Revision: 89837 U   branches/1.4/apps/app_queue.c ------------------------------------------------------------------------ r89837 | mmichelson | 2007-11-27 17:07:32 -0600 (Tue, 27 Nov 2007) | 12 lines Two changes with regards to the 'eventwhencalled' option of queues.conf 1) Due to some signed vs. unsigned silliness, setting 'eventwhencalled' to   'vars' or 'yes' did exactly the same thing. Thus the sign change of the   ast_true call. 2) The vars2manager function overwrote a for every channel variable it parsed, resulting   in bizarre output for the channel variables. This patch remedies this. (related to issue ASTERISK-10896, however I'm not sure if this will actually be enough to close it) ------------------------------------------------------------------------ By: Digium Subversion (svnbot) 2007-11-27 17:08:39.000-0600 Repository: asterisk Revision: 89838 _U  trunk/ U   trunk/apps/app_queue.c ------------------------------------------------------------------------ r89838 | mmichelson | 2007-11-27 17:08:39 -0600 (Tue, 27 Nov 2007) | 20 lines Merged revisions 89837 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r89837 | mmichelson | 2007-11-27 17:10:05 -0600 (Tue, 27 Nov 2007) | 12 lines Two changes with regards to the 'eventwhencalled' option of queues.conf 1) Due to some signed vs. unsigned silliness, setting 'eventwhencalled' to   'vars' or 'yes' did exactly the same thing. Thus the sign change of the   ast_true call. 2) The vars2manager function overwrote a for every channel variable it parsed, resulting   in bizarre output for the channel variables. This patch remedies this. (related to issue ASTERISK-10896, however I'm not sure if this will actually be enough to close it) ........ ------------------------------------------------------------------------ By: Mark Michelson (mmichelson) 2007-11-27 17:13:10.000-0600 I spotted a couple of errors regarding the 'eventwhencalled' option and committed fixes in svn revision 89837. This will fix the unreadable output of the manager as well as not printing out variables if you have not set the option to 'vars' What I'm still concerned about, though, is the error message you received before. If you don't mind, could you try running your dialplan with eventwhencalled set to 'yes' and again with eventwhencalled set to 'vars' and see if you still get that error? By: Andrey Solovyev (corruptor) 2007-11-28 04:47:09.000-0600 I tried running with eventwhencalled set to "yes". Output is ok. There is no Variables field. I've also uploaded the manager output when I set eventwhencalled=vars. There is no error but I don't know if the output is still correct. Those "STACK-..." variables with "in new stack" at the end look a little bit ugly :). By: Mark Michelson (mmichelson) 2007-11-28 14:25:06.000-0600 Yeah, those STACK variables appear to be every single priority of the dialqueue macro. I agree that those should probably not be output as channel variables. I will look into this and see if I can figure out what's happening. Thanks for your quick feedback! By: Mark Michelson (mmichelson) 2007-11-28 16:19:44.000-0600 I had a lengthy discussion regarding those STACK variables. It seems that if you have debug turned on, then every priority executed will be added as a channel variable. A few of us agreed that this was unnecessary, especially since these channel variables are not referenced anywhere else in the code. So, in revision 90059 of 1.4, I have removed the offending code. If not inclined to upgrade to that version, then those variables may be suppressed by turning off debug on the console. This issue is closed!