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.