[Home]

Summary:ASTERISK-12387: Once enabled the recording/monitoring will not disable
Reporter:Gabriel Ortiz Lour (elbriga)Labels:
Date Opened:2008-07-15 15:55:37Date Closed:2008-07-16 15:15:41
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_queue
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:The field "monitor-format" is used to control weather or not to record the queue calls. When I start my asterisk (tested on the last version, 1.4.21-1) with this field empty (in pgsql realtime) it wil not record the queue call. OK.
Then I set the monitor-format field to 'wav49', make a call, and it will record the call with the MixMonitor App. OK.
Now it's the problem! When I reset the field (empty string value) and make the same call, the MixMonitor App still starts and record the call, and will keep recording, no matter the value of the monitor-format field, until I unload/load the app_queue module or restart the Asterisk.
Comments:By: Mark Michelson (mmichelson) 2008-07-15 16:16:41

I see what the problem is. If an option is a zero-length string, then app_queue will not attempt to set the value. There are a few potential ways to accomplish this. I need to investigate which is the least likely to cause issues.

Thanks for the bug report!
By: Gabriel Ortiz Lour (elbriga) 2008-07-16 12:52:54

I solved my problem here by changing the line that controls the monitoring (app_queue.c:2884, right below the "/* Begin Monitoring */" line):

it was:
if (qe->parent->monfmt && *qe->parent->monfmt) {

changed to:
if (qe->parent->monfmt && strlen(qe->parent->monfmt) > 2) {

Since the three options for this param are: "gsm|wav|wav49"
It will only record if the param is at least 3 chars long.

Then I put something like "0" to disable the recording


By: Digium Subversion (svnbot) 2008-07-16 15:15:33

Repository: asterisk
Revision: 131369

U   branches/1.4/apps/app_queue.c

------------------------------------------------------------------------
r131369 | mmichelson | 2008-07-16 15:15:20 -0500 (Wed, 16 Jul 2008) | 14 lines

Move the init_queue call back to where it used to be (changed
Sept 12 last year). It was moved then to prevent a memory leak.
Since then, the same memory leak recurred and was fixed in a
better way.

Now it has been found that the placement of this init_queue
call can cause problems if a realtime queue has values changed
to an empty string. The problem is that the default value
for that queue parameter would not be set.

(closes issue ASTERISK-12387)
Reported by: elbriga


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=131369