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 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 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.
There's One Comment
The Digium Blog
- No items