Asterisk 18 - queue wrapuptime is inconsistent

When agents that are members of multiple queues get calls, the wrapuptime between the calls is consistently about 2/3’s the specified value. I have the wrapuptime set for 15 seconds on all queues, in reality it gets to about 8 - 12 seconds before sending a call to the agent. Also, occasionally the wrapuptime will be instantaneous or a couple of seconds.

If agents are just in one queue, the wrapuptime is 15 seconds most of the time, but even then occasionally it will be just a few seconds.

Anything I can do or check to work around or fix this? Or anything that I could look into?

I have shared_lastcall = yes in the queues.conf
I am using Asterisk 18.3.0

persistentmembers = yes
monitor-type = MixMonitor
shared_lastcall = yes
realtime_family = queues, queue_members

After more research on this topic, I have some testing feedback: I place a bunch of waiting calls into test queue, and then place my self dynamically into the queue as a queue member (using AddQueueMember() application in the dialplan). As I take the calls, sometimes I will hear beep with no call and then a beep with a call that would come a few seconds later. I would hang up the call and then get the next one 4 seconds later.

I think the wrapuptime started counting down at the time I got that phantom call with the first beep. Whenever I would get a beep with no call, the next time I do get a call connected, it has a significantly smaller wrapuptime.

There is an open issue regarding wrapuptime, shared_lastcall, and realtime[1].

[1] [ASTERISK-22589] shared_lastcall is not reliable with realtime queues - Digium/Asterisk JIRA

You could put a higher wrapuptime. Then unpause members programatically something like if last call was 15 seconds ago unpause member.

Update to this situation: Since I am using dynamic queues with a local channel as the member interface, I should be specifying a state_interface (6th parameter of the AddQueueMember) that is of the form PJSIP/xxxx Doing this the wrap up time works perfectly. I read that the local channel state does not always represent what is really going on with the endpoint.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.