<div>Hi Anthony</div>
<div> </div>
<div>Thanks for your response, sorry for the delay, but for some reason I did not see it until now. </div>
<div> </div>
<div>To be honest I think the whole point of fifo is to keep it simple and let mod_callcenter do the more advanced stuff and that it specifically why I went for it after having read both wiki pages quite thoroughly.</div>
<div> </div>
<div>But there is still something I don't understand on how the default behaviour ring-all with CLI works. According the logic you have described below. it looks as if the call gets only presented to one agent at a time. however when testing it, it looks as is the calls gets sent out with the CLI to all agents who are available. Is that what you'd expect?</div>
<div> </div>
<div>Thanks</div>
<div>Marc</div>
<div><br><br> </div>
<div class="gmail_quote">On Mon, Mar 21, 2011 at 10:26 PM, Anthony Minessale <span dir="ltr"><<a href="mailto:anthony.minessale@gmail.com">anthony.minessale@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">The ringall strategy is based on giving every queue a fair chance<br>based on its configured importance.<br>
<br>The following happens nonstop:<br><br>*) Loop all the active call queues containing waiting callers not<br>already receiving a call sorted on queue priority:<br> *) Select agents from a db (omitting any who are on a call or<br>
who are in wrap-up) sorted by<br> least amount of consecutive missed calls then least amount<br>of answered calls.<br>*) Place an outbound call to this agent with the caller data of the<br>waiting customer<br><br>
This distributes the opportunities to have your call answered across<br>all queues and chooses the most-likely-to-answer-the-phone agent.<br><br><br>The shortcoming of this strategy is simply the fact that you must<br>pre-allocate agents for each caller to ensure that you can supply the<br>
caller's caller id to the agent when you call them.<br><br>The enterprise one is accelerated by figuring out how many callers are<br>waiting and calling that many agents at once with no caller id info<br>and inserting them into the queue to service the next customer in<br>
line. Since there is no need to pre-match the caller and agent the<br>order of what agent and caller are paired is moot. This was the<br>original behavior but the importance of caller id seems to prevail so<br>we made the other method the default.<br>
<br>It would be possible to code in other strategies but to maintain the<br>simplicity of fifo I did not really bother with any more.<br>
<div>
<div></div>
<div class="h5"><br><br><br><br><br><br><br><br>On Mon, Mar 21, 2011 at 12:59 PM, Marc de Corny <<a href="mailto:marcdecorny@gmail.com">marcdecorny@gmail.com</a>> wrote:<br>> Hi all,<br>> I am getting the hang of the fifo now and it is proving very stable which is<br>
> what we all need.<br>> Got one question however regarding mod_fifo and the outbound strategies.<br>> From looking at the outbput of the fifo list commands I can see that that<br>> parameter is always set to "ringall". which is fine, but I can also see many<br>
> stats on that number of calls and the last call that the members have taken.<br>> Is there also a way of sending the calls to the longest idle or something of<br>> that nature? Is that done by setting the outbound_strategy to "enterprise"<br>
> or is there another way to achieve that.<br>> Is there also a command to change that value without editing the XML as I am<br>> trying to make everything dynamic.<br>> any input is very much appreciated.<br>
> thanks<br>> Marc<br></div></div>
<div class="im">> _______________________________________________<br>> FreeSWITCH-users mailing list<br>> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>> <a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org</a><br>
><br>><br><br><br><br></div>--<br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/" target="_blank">http://www.cluecon.com/</a><br>
Twitter: <a href="http://twitter.com/FreeSWITCH_wire" target="_blank">http://twitter.com/FreeSWITCH_wire</a><br><br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>
GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>IRC: <a href="http://irc.freenode.net/" target="_blank">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br>
<a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br><a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>pstn:+19193869900<br>
</blockquote></div><br>