[asterisk-bugs] [Asterisk 0012771]: Bogus <member> is still 'Not in Use' warnings for AgentLogin'ed agents.
noreply at bugs.digium.com
noreply at bugs.digium.com
Mon Jun 2 12:01:39 CDT 2008
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 12:01 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.
======================================================================
----------------------------------------------------------------------
davidw - 06-02-08 12:01
----------------------------------------------------------------------
I think it is worth noting http://bugs.digium.com/view.php?id=0012709 and
http://bugs.digium.com/view.php?id=0012492 which show that other
people have this happening as well.
I can try separating the peer and user functions (although I need to
confirm that this is acutally possible when there is a subscription).
However, are you saying that, even when SIP was not in a position to give
accurate presence, you still weren't getting the warning? We have 1800+ of
these messages (across several versions of 1.4) in the last month, on a
test system that has just one, rather part time, agent.
My assumption was that it was trying to do presence on the underlying
channel, not the agent. It looks like it might be doing it on the agent,
in which case there is maybe a race condition.
It looks like it is a race condition - note that a different thread does
the test from the one that updates the status; it is the actual channel
whose status is updated synchronously, but it is the member structure whose
state is checked, and the update to that is queued:
[Jun 2 17:23:42] DEBUG[25994] devicestate.c: Notification of state change
to be queued on device/channel Agent/1001
[Jun 2 17:23:42] DEBUG[23452] devicestate.c: Changing state for
Agent/1001 - state 3 (Busy)
[Jun 2 17:23:42] WARNING[25994] 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.
[Jun 2 17:23:42] DEBUG[25994] devicestate.c: Notification of state change
to be queued on device/channel Local/XXXXXX at YYYYYYY-2a56,2
[Jun 2 17:23:42] DEBUG[25994] devicestate.c: Notification of state change
to be queued on device/channel Local/XXXXXX at YYYYYYY
[Jun 2 17:23:42] DEBUG[23477] app_queue.c: Device 'Agent/1001' changed to
state
'3' (Busy)
Issue History
Date Modified Username Field Change
======================================================================
06-02-08 12:01 davidw Note Added: 0087663
======================================================================
More information about the asterisk-bugs
mailing list