[asterisk-bugs] [Asterisk 0012127]: Using state_interface and Local channels allows several simultenous calls to be sent to agent

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12127 
====================================================================== 
Reported By:                atis
Assigned To:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   12127
Category:                   Applications/app_queue
Reproducibility:            sometimes
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 103809 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             03-03-2008 12:26 CST
Last Modified:              03-10-2008 08:52 CDT
====================================================================== 
Summary:                    Using state_interface and Local channels allows
several simultenous calls to be sent to agent
Description: 
I've seen this situation on 8-CPU 3GHz Xeon, that agent gets 4 queue calls
simultaneously. 

For now i've been able to avoid this by checking/setting group at
beginning of Local channel, setting call-limit=1 for SIP peers (only for
those who shouldn't receive more than 1 call simultaneously) and checking
group upon unsuccessful Dial from Local channel. Those 3 fixes together are
giving some good results for one most-problematic queue, however that's not
a permanent and stable solution. If queue is creating several channels at
the same time, on slower but multi-cored systems this could lead to race
condition between GROUP_COUNT and Set(GROUP()) in two parallel channels,
and call-limit=1 also can't always be set.

I'm not sure if this can be implemented in good way, but I think the most
appropriate solution for this would be that Queue is setting device state
of Local channel, and other queue(s) (if member is in multiple queues)
receives event from first queue's devicestate change.

My system is Asterisk 1.4.14 with backported state_interface from r103809
====================================================================== 

---------------------------------------------------------------------- 
 atis - 03-10-08 08:52  
---------------------------------------------------------------------- 
Update: i found the problem with performance and lot of simultenous calls,
and that's not what i've described before. Silly, but it was ringinuse
parameter that defaults to 1.

However there's still a window where app_queue might dial to local channel
when it's already being used. I followed status change, and seems that
problem lays within update_dial_status. I have no idea how that's supposed
to work, but it doesn't work correctly in combination of local channels and
state_interface. For example if app_queue dials to local channel,
update_dial_status sets queue member's state to UNKNOWN, regardless of dial
result. If dialplan finally does Dial() to the same agent who's state
interface is set in queue_members everything is ok, as handle_statechange
gets executed upon ringing, and further status updates are correct (but
there's a window until that when other thread can dial same agent). If
dialplan doesn't dial actual SIP extension, queue will still update it's
status trough update_dial_status, and queue member will remain in UNKNOWN
state (or RINGING if this fix applied).

My setup is currently working quite good with call to update_status()
commented out within update_dial_status, but it's first day since i put
that in production. Generally it would be good if there would be some
option, how to configure this, but i'll need some more understanding on
update_dial_status and what it does. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-10-08 08:52  atis           Note Added: 0083658                          
======================================================================