asterisk users - Jan 2010 - queue groups in asterisk 1.4

This email is not a question, but a potential solution to any who have 
had the same issue I have faced.

If you have agents logged in to multiple queues at the same time, 
Asterisk does not handle the answering of those queues in any set order 
or sequence.  It has no way of prioritizing calls in between the shared 
queues, to guarantee that the queue with the call that has the longest 
hold time will be answered next.

If Asterisk is configured with several queues and all queues have calls 
waiting, when an Agent becomes available, Asterisk randomly picks the 
queue that will be answered next. This can be a problem adversely 
affecting service levels since the queue with the call having the 
longest hold time may be essentially ignored for several cycles of 
available agents.

To fix this issue, we had a custom patch written for the 1.4 branch.  
Digium has decided to not include it in the 1.6 branch, so I am making 
the 1.4 patch available for any who want or need it.  It works well on 
1.4.19.1, but I have not tried it on anything after that (I am currently 
running 1.6 and have the issue back again).

Questions are always welcome, though I may or may not have the answers, 
as I am not the coder, just the asterisk admin.

As always, if you need it/ want it in your production systems, it would 
be good to send an email to Digium letting them know that.

-Steve

Patch at:  http://mirrors.bluehost.com/asterisk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5515 bytes
Desc: S/MIME Cryptographic Signature
Url :
http://lists.digium.com/pipermail/asterisk-users/attachments/20100120/952226a1/attachment.bin

Maybe I'm saying something stupid, but I thought this was what
shared_lastcall would do with a leastrecent strategy.

; shared_lastcall will make the lastcall and calls received be the same in
; members logged in more than one queue.
; This is useful to make the queue respect the wrapuptime of another queue
; for a shared member
;
shared_lastcall=no

I did not really try it, just read the docs.
l.




2010/1/20 Steven Alligood <steve at bluehost.com>
> This email is not a question, but a potential solution to any who have had
> the same issue I have faced.
>
> If you have agents logged in to multiple queues at the same time, Asterisk
> does not handle the answering of those queues in any set order or sequence.
>  It has no way of prioritizing calls in between the shared queues, to
> guarantee that the queue with the call that has the longest hold time will
> be answered next.
>
> If Asterisk is configured with several queues and all queues have calls
> waiting, when an Agent becomes available, Asterisk randomly picks the queue
> that will be answered next. This can be a problem adversely affecting
> service levels since the queue with the call having the longest hold time
> may be essentially ignored for several cycles of available agents.
>
> To fix this issue, we had a custom patch written for the 1.4 branch.
>  Digium has decided to not include it in the 1.6 branch, so I am making the
> 1.4 patch available for any who want or need it.  It works well on
1.4.19.1,
> but I have not tried it on anything after that (I am currently running 1.6
> and have the issue back again).
>
> Questions are always welcome, though I may or may not have the answers, as
> I am not the coder, just the asterisk admin.
>
> As always, if you need it/ want it in your production systems, it would be
> good to send an email to Digium letting them know that.
>
> -Steve
>
> Patch at:  http://mirrors.bluehost.com/asterisk
>
>
> --
> _____________________________________________________________________
> -- 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
>


-- 
Loway - home of QueueMetrics - http://queuemetrics.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20100122/314492cb/attachment.htm