> 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 _______________________________________________ Sign up now for AstriCon 2007! September 25-28th. http://www.astricon.net/ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
