[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-11-2008 11:50 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
====================================================================== 

---------------------------------------------------------------------- 
 putnopvut - 03-11-08 11:50  
---------------------------------------------------------------------- 
Good find, folks! I had a look at the update_dial_status and update_status
functions and had a discussion about them with Russell.

So here's the deal...those functions are in app_queue and predate the use
of device state as the indicator for member status. There are three places
where update_dial_status is called, and only one of those places actually
makes any sense. It is called in ring_entry in the case that ast_request
fails. The other two uses are immediately after a call to ast_request if
the status returned from ast_request is different than the status we had
for the member. Here's the problem with that comparison: ast_request
returns a cause code, and the member's status is a device state value, so
the two values are incompatible and it makes no sense to compare them.
Definitely buggy.

Then, within update_dial_status, there is some more bugginess. Only three
of the many cause codes are actually handled, and if any other cause is
sent back, the member's status is set to "unknown."

But the main thing that bothers me is that even with all the weird things
going on with update_dial_status and update_status, none of it should be
necessary now because of the device state code. I'm going to investigate a
bit further and see if there actually IS any reason to have those functions
in the source.

Once again, great find! 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-11-08 11:50  putnopvut      Note Added: 0083726                          
======================================================================