Thanks, I hadn't seen those posts before.
Unfortunately, we have tried incominglimit/outgoinglimit (both of which are server-centric, not user centric, so incominglimit actually limits the number of calls incoming to the server from the user, not the other way around. outgoinglimit is what would limit the number of calls sent from the server to the agent, but it is VERY deprecated and to my knowledge never worked right). We also utilized SetGroup/CheckGroup which works pre 1.2, and the new GROUP/GROUP_COUNT functions in 1.2.
None of the above solutions works in the queue environment. I'm assuming this is because the queue application uses a separate call handling algorithm (it doesn't use a standard context) and thus there is no way of defining a call limit, etc, for multi-line phones.
I did read a post to the Asterisk-dev mailing list where a user had patched the queue source code to include a SetGroup/CheckGroup, but I have been unable to proceed further.
It actually is a missing feature or at least an oversight the queue application, though - if you consider what a queue is supposed to do, then having logic where multiple calls are routed to agents already on calls points to a flawed logic, at least in my mind. Note that we are using dynamic agents through the AddQueueMember/RemoveQueueMember functions. This is because our managers need to be able to take people in and out of queue, and to do this, we are using the AsteriskGuru Operator Panel, as well as extensions the users can dial to take themselves in and out of queue. We are big enough (~350 seats across 7 internal divisions) that we need such tools to keep track of what is going on.
Another interesting thread about this issue:
asteriskguru.com/archives/sv ... iple+calls
In any case, I am still searching for the perfect solution to this problem. A single line phone works great, but we haven't found one that is acceptable for our needs, and our users will need to change the number of available lines throughout the day based on call load, etc - we have a very complicated environment here and working around it can suck.
In any case, thanks for the input, and if anyone has any further suggestions, I'd love to hear them!