leastrecent suffers the same fait as fewestcalls onlying ringing the leastrecent agent over and over endlessly. It should have a fallback option.
roundrobin with leastrecent first roundrobin with fewestcalls first I would like to see a roundrobin with leastbusy first option. (just because you have taken less call or leastrecent doesn't mean you haven't been a busy agent!) I'm sure better autologoff logic as per my first email would be a great idea also. bkw On Sun, 10 Aug 2003, Richard Lyman wrote: > well if you ask me, the leastrecent part would work if you reversed the > logic on the metric. > > my other last_used mod would do a time_t on that agent the last time it > was 'tried' (ast_request'd) then (i was using arrays) qsort so that (new > agents) '0' would be on top, and the agent that got the most recent > attempt would be on the bottom '1057174447' (below is an example) > > -- sorted agent array: 317 last_used: 0 > -- sorted agent array: 318 last_used: 0 > -- sorted agent array: 319 last_used: 0 > -- sorted agent array: 300 last_used: 1057174447 > > that way, (for leastrecent anyway), you are always working with a full stack of > agents. > > > > Brian West wrote: > > >First of all I would like to thank Mark for getting roundrobin to go > >roundrobin. Good job. > > > >Now we have some options here for leastrecent and fewestcalls strategy. It > >needs some work on the logic and Mark recommend that I ask the list and > >get some input before he makes any changes to it. > > > >fewestcalls from what I have seen would always ring the agent with the > >fewestcalls first then go into roundrobin if that agent didn't answer. > > > >Next new caller would ring fewestcalls agent first then start roundrobin. > > > >What do you think should happen in fewestcalls? Right now it just rings > >the agent with the fewestcalls over and over with current app_queue logic. > > > >leastrecent from what I have been looking at will ring the agent that has > >least recently take a call first then if they don't answer go into > >roundrobin. Then the next new call coming from queue would first go to > >the leastrecent first then try every agent in roundrobin till answered > >then starting over again. New caller from queue hits leastrecent agent > >first. > > > >Same thing happens in leastrecent strategy. The leastrecent agent will > >ring over and over with current app_queue logic. > > > >Now some of you might recommend autologoff options. But that also might > >need some work. I don't want to log off an agent for not answering the > >phone only once. So here is how I would like to see autologoff work. > > > >Example: > >queue timeout = 20 > >agent autologoff = 60 > > > >The agent would have to not answer their phone 3 times in a row to get > >logged off. As it stands now they did not answer just once and get logged > >off. Thus allow for an employee to use the excuse for not working when > >they should be logged in and taking calls. > > > >Unless i'm wrong here. > > > >Please post your input on these options and how you would like them to see > >them function function. > > > >Thanks, > >Brian > >CWIS Internet Services > > > > > >_______________________________________________ > >Asterisk-Users mailing list > >[EMAIL PROTECTED] > >http://lists.digium.com/mailman/listinfo/asterisk-users > > > > > > > > _______________________________________________ > Asterisk-Users mailing list > [EMAIL PROTECTED] > http://lists.digium.com/mailman/listinfo/asterisk-users > _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
