Yes it seems... but not just with that strategy. Now I'm working on a queue witch I need to go to agent 1004, then 1018 and then 1010 so I wrote this in queue.conf:
[general] persistentmembers = yes autofill = yes monitor-type = MixMonitor [FAC] musicclass = default strategy = roundrobin servicelevel = 60 timeout = 10 retry = 10 weight=0 wrapuptime = 0 maxlen = 0 periodic-announce-frequency=60 periodic-announce = Track1 joinempty = no leavewhenempty = yes ringinuse = no timeoutrestart = yes member => Agent/1004 member => Agent/1018 member => Agent/1010 ;member => Agent/1011 But what happens is it behaves has "rrmemory" since it remembers the last agent it rang, and instead if using the order I specified, it goes "sorted" (1004, then _1010_, and only then 1018). Asterisk is a great piece of software, a lot more stable then what it was 2y ago, but there are some "basic bugs" that I can't understand why they still happen... I'm one of the very few persons that use it for queues? Thank you for your comments and help. Cheers, Marco. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jakub Glazik Sent: sexta-feira, 27 de Julho de 2007 12:55 To: asterisk-users@lists.digium.com Subject: Re: [asterisk-users] Queues strategy "leastrecent" Dnia 2007-07-27, o godz. 11:09:37 "Marco Campos" <[EMAIL PROTECTED]> napisał(a): > I think this strategy should work like this: > a) Make a list of available agents and their idle time (time > since last call) and update it each time a call gets answered or ends > b) When a call comes in, try to pass it to the first agent on > that list > c) If the timeout ("timeout = 10") is reached it should try the > next (second in this case) agent on that list > d) .and so on. > But what I see is that it is always trying to pass the call to the > same agent, since it thinks that that agent is idle longer than any > other. > Are any of your seen a similar problem, and eventually know how to > fix this? I think the same and I have the same problem with leastrecent (1.4.7.1). I believe that current behaviour is buggy and not useful. -- .: Jakub Głazik, .: email & jabber: zytek<at>nuxi.pl _______________________________________________ --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 _______________________________________________ --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