[asterisk-bugs] [Asterisk 0012771]: Bogus <member> is still 'Not in Use' warnings for AgentLogin'ed agents.

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12771 
====================================================================== 
Reported By:                davidw
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12771
Category:                   Applications/app_queue
Reproducibility:            always
Severity:                   tweak
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.20.1 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             06-02-2008 09:57 CDT
Last Modified:              06-02-2008 15:59 CDT
====================================================================== 
Summary:                    Bogus <member> is still 'Not in Use'  warnings for
AgentLogin'ed agents.
Description: 
Asterisk seems to correctly know when an AgentLogin type agent is busy on a
call, however every time our agent gets a call, we get a message like:

WARNING[16777] app_queue.c: The device state of this queue member,
Anonymous, is still 'Not in Use' when it probably should not be! Please
check UPGRADE.txt for correct configuration settings.

We've tried to get good presence information from the SIP phones that are
logging in as the agents, but haven't found a recipe that does achieves
this for outgoing calls.  However, this should be irrelevant as it is the
Agent itself whose state matters, not that of the SIP phone.  Moreover, for
AgentLogin, the busy state on the phone wouldn't change for each call, but
would cover the whole logged in period.

====================================================================== 

---------------------------------------------------------------------- 
 putnopvut - 06-02-08 15:59  
---------------------------------------------------------------------- 
Excellent analysis on the race condition. I removed all options from my
queue which could cause  delay between when the agent answers and when that
message appears (for instance, I had a two second member delay), and sure
enough, I was able to make it happen.

As far as the impact this has, my quick analysis (meaning going through
the scenario in my head, not necessarily combing all code paths) is that it
may be possible for a second call to reach the agent before the device
state change is noticed by app_queue (although I highly doubt it would
happen given the amount of locking necessary before a call finally reaches
an agent). If this were to happen, and the proper options were in place,
that new caller may end up getting kicked from the queue. That's about the
worst I can think of happening here as it is, so this is probably a "minor"
issue. 

As a temporary workaround, you can add in a 1 second member delay to your
queue. I'm not going to make any guarantees one way or another, but I would
be willing to bet that fixing such a race condition may be quite an
undertaking. I'll have a closer look and see how much work it will take. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-02-08 15:59  putnopvut      Note Added: 0087678                          
======================================================================