Delay between ringing members in queue

Hello. I am using a queue with linear strategy and static members. Asterisk correctly rings members in sequence, however there is a 2-3 second delay after one member stops ringing and before next member starts ringing. I would like to eliminate this delay, but I can’t find any parameter that controls it. Asterisk version is 15.1.5. Queues config:

[general]
autofill=yes
shared_lastcall=yes
monitor-type=MixMonitor
updatecdr=yes
persistentmembers=yes

[StandardQueue](!)
strategy=linear
joinempty=no
leavewhenempty=yes
ringinuse=no
timeout=12
maxlen=0
retry=0
announce-position=no
periodic-announce=pleasehold
periodic-announce-frequency=20
setqueueentryvar=yes
setinterfacevar=yes

[Q0800](StandardQueue)
member => PJSIP/201
member => PJSIP/202
member => PJSIP/203
member => PJSIP/204
member => PJSIP/205

retry would be the parameter, but I’m not sure you can set it to zero.

Thanks for the reply. Asterisk documentation in some places indeed states that “retry” parameter controls delay between calling individual members, but after inspecting source code I’ve confirmed that it actually controls the delay after going through entire agent list and trying everyone again. From app_queue.c:

int retry; /*!< Retry calling everyone after this amount of time */

It’s the delay after timeout expires. It will only go through the whole list if all the other ones actively reject the call. At least that is how I recall it to work

1 Like

OK, I found out in the end, ‘retry’ is the parameter that controls delay between dialing agents, and indeed it can’t be zero (so 1 second is the minimum).

Why retry cannot be 0? Is there some reason for this? I still see this in Asterisk 17.9.0 source code:
3266 } else if (!strcasecmp(param, “retry”)) {
3267 q->retry = atoi(val);
3268 if (q->retry <= 0) {
3269 q->retry = DEFAULT_RETRY;
3270 }

The place to ask this is asterisk-dev mailing list, but I suspect that the answer will be that nobody remembers.

The only reason I see is to not overload server with continuously checking all extensions, when all agents are busy (this will also generate a huge log). But in case queue strategy is rrmemory or similar, agent timeout is 15 seconds, maxwaittime is 60 seconds for example, if first agent does not answer it is reasonable to have retry option of 0 - this will allow 4 agents to ring for 15 seconds each instead of 3 with retry 5 seconds.