The app_queue module is one of the oldest modules in Asterisk and implements call queueing functionality. You configure a queue with members and a strategy and these members receive calls as appropriate. The queue knows whether a member is reachable or not by looking at the device state (the same thing you see if your SIP phone subscribes to know the state of an extension) and in recent times by internally keeping track of whether they were in a call or not.
The additional logic to keep track of queue members being in calls was added[1] to fix a race condition with the wrapup time option. It was possible for the queue to see that a queue member was available BEFORE the wrapup time was updated, causing them to receive a call immediately instead of receiving a wrapup time. By keeping track of whether the queue member was in a call in the queue this was solved… but there were unforeseen consequences that were brought up in various bug reports.
There are some scenarios involving queues which result in a caller being in the queue connected to a channel that is not the queue member. This most commonly occurs when a Local channel is used as a queue member and a transfer occurs on it. In this case the transfer occurs outside the scope of the queue, so it remains connected to the Local channel in the queue but not to the queue member. The additional logic that was added to keep track of a queue member being in a call did not take this into account. The device state of the queue member would say it is available but the queue would mistakenly think they were still in a call.
To resolve this problem a new approach[2] was taken to fix the original issue. The logic which kept track of whether a queue member was in a call or not was removed. Instead when a queue now receives notification that a queue member is available it will update the wrapup time immediately before the logic that determines if a queue member can be called executes. This ensures there is no window where the queue member is available and the wrapup time is incorrect. The newly introduced problem was also resolved as there is no logic any longer for keeping track of a queue member being in a call that is consulted when determining if the queue member can be called.
[1] https://gerrit.asterisk.org/#/c/1880/
[2] https://gerrit.asterisk.org/#/c/5639/
One Response
This has come up recently with users of our Asterisk-based systems. Two main unwanted behaviors are reported, when using Local/ channels for agents:
1. An agent transfers a call away and is not released for new calls until the original call has completed (as described in the article)
2. An agent transfers a call and the queue log indicates call complete instead of transferred
What surprised me on digging deeper is that a transfer to another agent of the same queue is not handled “intelligently” by app_queue. I would have imagined that a very common use case would be transferring a call for handling by a requested or known agent, perhaps re-queuing the call with an agent-affinity type tag so that it is preferentially distributed to the selected agent. Implementation anyone? Or is this a case for external ARI-driven logic?