On 9/7/07, <b class="gmail_sendername">Mark Michelson</b> <<a href="mailto:mmichelson@digium.com">mmichelson@digium.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
After talking in #asterisk-dev with those who wrote the joinempty<br>option, it appears I was mistaken about its use. joinempty=strict will<br>only not allow a caller to join the queue if the members are in a<br>"permanently" unavailable state. A member being busy is not enough to
<br>trigger the joinempty=strict option. Since DND on most phones works the<br>same way as a phone being busy, DND will not trigger the<br>joinempty=strict option either.</blockquote><div><br>It's also important to distinguish between DND-style busy (where in the case of SIP the INVITE is rejected with a "480 temporarily unavailable") and the internal channel state AST_CONTROL_BUSY. For SIP, the latter occurs when the use count exceeds the configured call-limit, and results in no INVITE being sent. The two also have drastically different behaviours when you have members with penalties.
<br><br>Assume we have five agents with penalty zero (A-E) and five agents with penalty 1 (F-J). Assume also that 'ringinuse=no' is set for the queue. If A-D are "in use" and E is "available" but their phone is set to DND, then app_queue will continually attempt to dequeue to agent E, never trying agents F-J. If E is busy because they have a call-limit of 2 and they have two calls active, then app_queue will attempt to dequeue to agents F-J.
<br><br>This has been a source of confusion for my users on several occasions. IMO, It also puts an unrealistic burden on agents to always put themselves on pause before they walk away from their desk, and since agents are human and sometimes forget to do this, prevents me from using agent penalties extensively. I just can't explain to non-technical people why one phone keeps ringing while five other agents sit idle. It makes no sense to them.
<br><br>Someone developed a new strategy for app_queue they called XRRMEMORY that will seek to higher-penalty agents after trying all lower-penalty agents. They posted details about it on voip-info:<br><br><a href="http://www.voip-info.org/wiki/index.php?page=Asterisk+cmd+Queue">
http://www.voip-info.org/wiki/index.php?page=Asterisk+cmd+Queue</a><br><br>(look at the second comment)<br><br>Unfortunately, the patches weren't done against trunk or the head of 1.4, and the author didn't file a disclaimer with Mantis, so the bug (
<a href="http://bugs.digium.com/view.php?id=9165">http://bugs.digium.com/view.php?id=9165</a>) was recently closed.<br></div><br></div>-- <br>j.