Summary:ASTERISK-12445: Queues: retry setting has no effect
Reporter:fresshness2001 (fresshness2001)Labels:
Date Opened:2008-07-24 10:32:19Date Closed:2011-06-07 14:08:28
Versions:Frequency of
Description:Using asterisk 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.


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.