[asterisk-dev] Proposal for changes to static queue configuration

[Norman Franke]

> Jared Smith wrote:
>> I wholeheartedly agree!  We really need to get past our current queue
>> code and write it's replacement, instead of just applying band- 
>> aids to
>> the current code.  I pushed for this at the Asterisk Developers
>> Conference this spring, and I'm more than happy to help coordinate  
>> the
>> effort of gathering requirements, defining use cases, and testing.
>> Unfortunately, my coding skills in C are so rusty right now I can't
>> really help out in that department.
>
> That would be great if you would be willing to help out with  
> gathering and
> documenting the requirements for queues-ng.  That has to get done  
> before we can
> get anywhere with its development since this is a larger scale  
> development effort.
>
> I know from conversations we have already had that this going to be  
> more than
> writing a new app module.  It's going to require some core  
> architecture
> development, as well.  Given that, I'd like to approach the project  
> in a
> structured way so that we don't miss anything or waste time working  
> on stuff
> that isn't going to satisfy what people want in the end.

I'm interested in what other features other people find interesting.

I found the existing app_queue rather inadequate in many ways, many  
coming down to how it makes decisions on which call is next. As a  
result, I've stripped app_queue of many things I don't care about and  
added in a master thread to coordinate mapping between callers and  
members. I could see extending this like app_externalivr to have an  
external process make the mapping, allowing for a flexible model to  
implement things like priorities, skills based routing, etc.

I've also been exploring personal sub-queues, which allows each  
member to have a "direct line" that can be queued as part of the main  
queue. It allows for things like "I was talking to Jane and wanted to  
speak with her again" to forward that call to Jane such that she gets  
it as her next call. Another crazy feature I'm tinkering with is  
queue attributes based on the incoming number (DID) allowing for  
different behavior depending as needed, e.g. music on hold vs  
ringing, max hold time, etc. This clients X, Y and Z can use  
potentially different music on hold channels while A and B just ring.  
Granted this can be done now with variables, I believe, but it seems  
easier to just have the queue look it up in a database.

I'd be happy to work with someone on a rewrite, depending on how  
drastic of a rewrite we are talking about.

Norman Franke
ASD, Inc
www.myasd.com