We just recently upgraded from Asterisk 1.2 to 1.4, and quickly noticed a change in the behaviour of the queues--a change that we cannot live with.
We've used AddQueueMember/RemoveQueueMember to manage logging into and out of our queues for over a year now with Asterisk 1.2, and in that version the queue members were sorted in such a way that the person who had been logged in the longest would be the first one to get a call. But when we deployed 1.4 last week, we noticed that the member list was no longer sorted based on login time. It seemed to have a pre-set order that members were always placed into. After looking at the code (apps/app_queue.c), I found the cause of this. In 1.2, the members were stored in a linked list, so when someone logged in, they were placed at the end, and when calls were handed out, it was done starting at the front of the member list (or vice-versa, but either way, it has the same effect). In 1.4, the member list was changed to an "ao2_container", which apparently uses a hash table, and iterates through the list in a fixed order, meaning one of our agents is always the favourite for a call, and it is quite unfair. Now, I know that the ordering of members in the queue in 1.2 was not documented, and it may not have even been intentional, but it was very appropriate for our business model, and we'd like to find a way to get it back. Is there a way to control the order in which the ao2_iterator returns the items? Even a random distribution would be better than the current--which always favours some agents over others. And before anyone mentions the "strategy" setting in queues.conf, I should say that we use "leastrecent", but because of the ratio of agents to queues in our business, the strategy doesn't come into effect immediately. With many agents answering each queue, it takes a while for each of them to get a call. Until then (which usually takes about half of each day), the calls are distributed based on the ordering of the member list. We have switched to the "rrmemory" strategy for now, but we've yet to notice what effect that has--and our ideal would be to use "leastrecent" along with the behaviour that Asterisk 1.2 exhibited. Thanks! -- cc -Wall The Lodging Company http://www.skihills.com/ OpenPGP Public Key ID: 0x262208A0
signature.asc
Description: OpenPGP digital signature
_______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
