Summary:	ASTERISK-12445: Queues: retry setting has no effect
Reporter:	fresshness2001 (fresshness2001)	Labels:
Date Opened:	2008-07-24 10:32:19	Date Closed:	2011-06-07 14:08:28
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Using asterisk 1.4.20.1 on CentOS 5.1. No matter what value I fill in on the 'retry' parameter, it always 'retries' after 1 minute, not the indicated amount of seconds. ****** ADDITIONAL INFORMATION ****** [Test] musiconhold = default strategy = roundrobin servicelevel = 0 timeout = 3600 retry = 15 weight = 1 wrapuptime = 5 maxlen = 500 announce-frequency = 0 periodic-announce-frequency = 0 announce-holdtime = 0 monitor-format = wav monitor-join = yes joinempty = 1 leavewhenempty = no eventwhencalled = no reportholdtime = 0 member => sip/1006 member => sip/1010 member => sip/1002 member => sip/1003
Comments:	By: Mark Michelson (mmichelson) 2008-07-24 10:59:17 Could you describe the problem in more detail? Right now, I am convinced that the problem is a configuration issue due to a misunderstanding of queues.conf options since the option works fine in my test setup. Just to be clear, the behavior you should see based on that configuration is the following: 1. Caller enters the queue 2. Caller attempts to call a queue member 3. The queue member's phone will ring for 3600 seconds (timeout option) 4. The queue will wait for 15 seconds (retry option) 5. Go to step 2. Is all of the above happening correctly except for step 4? By: fresshness2001 (fresshness2001) 2008-07-24 11:25:21 putnopvut, that is correct. Everything is correctly happening, except step 4, which is not 15 seconds, but 60 seconds. Could there be a (global) variable or variables that may affect this behavior? By: fresshness2001 (fresshness2001) 2008-11-12 05:22:50.000-0600 Is there any update regarding this point? By: Mark Michelson (mmichelson) 2008-11-12 09:30:57.000-0600 Sorry about the lack of updates on this. I've been busy with other issues. I realize at this point that I never asked for any sort of debug output from you on this, which is very remiss of me. Issue the CLI command "core set debug 10" and place a call which exhibits this behavior. Upload the console output and perhaps I'll be able to see exactly what is going wrong, since I have not been able to reproduce this in a test setup. By: fresshness2001 (fresshness2001) 2008-11-12 09:37:30.000-0600 It's time for me to apologize. The value gets used correctly now. I'm quite dumbfounded to see this as I'm 100% certain the system always used 60 seconds nomatter what was filled in as wrapuptime value. Again, my apologies You can close this issue (I would have, but I cannot see how I can do this). Thank you By: Mark Michelson (mmichelson) 2008-11-12 10:01:50.000-0600 It's no problem at all. No apology needed :) I'll close the issue right away.