[asterisk-bugs] [Asterisk 0012672]: Device State stay stuck to "inuse" causing agent not to receive anymore call
noreply at bugs.digium.com
noreply at bugs.digium.com
Fri Jul 4 07:58:57 CDT 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=12672
======================================================================
Reported By: dimitripietro
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 12672
Category: Channels/chan_sip/General
Reproducibility: sometimes
Severity: major
Priority: normal
Status: feedback
Asterisk Version: SVN
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.0
SVN Revision (number only!): 116139
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 05-16-2008 21:49 CDT
Last Modified: 07-04-2008 07:58 CDT
======================================================================
Summary: Device State stay stuck to "inuse" causing agent not
to receive anymore call
Description:
Sometime during the day, I have some SIP device state that stay stuck to
"inuse" causing asterisk not to send anymore call to the agent using this
SIP Phone (Polycom 2.2.084). It seem that the device state stay "inuse"
only for channel being part of one of my queue (agent) and not to regular
extension (administration).
I'm using :
- AddQueueMember
- Local channel/n as member with a stateinterface (SIP/XXX)
- ringinuse=no
In attachement, a copy of my queues.conf and my login dialplan.
PS : I had the same prob with beta 8.
======================================================================
----------------------------------------------------------------------
aragon - 07-04-08 07:58
----------------------------------------------------------------------
corydon76
Using QueueAddMember and putnopvut revision for state_interface it is
possible for agent to be available after call is transferred see bug ID
11603
Repository: asterisk
Revision: 97203
U trunk/CHANGES
U trunk/apps/app_queue.c
U trunk/configs/queues.conf.sample
------------------------------------------------------------------------
r97203 | mmichelson | 2008-01-08 15:14:44 -0600 (Tue, 08 Jan 2008) | 8
lines
Adding the option of specifying a second interface in a member definition
for a queue. app_queue
will monitor this second device's state for the member, even though it
actually calls the first
interface. This ability has been added for statically defined queue
members, realtime queue members,
and dynamic queue members added through the CLI, dialplan, or manager.
(closes issue 0011603, reported by acidv)
------------------------------------------------------------------------
http://svn.digium.com/view/asterisk?view=rev&revision=97203 [^]
I have been able to collect some information which I hope is useful and it
seems that there are many open bugs related to this same issue
I have problems with agents receiving multiple calls when available.
Usually when agent returns to ready state from pause because there are many
callers waiting in queue. On occasion an agent to receives as many calls
simultaneously as defined in call limit.
Reducing call limit is not practical or a good solution. Setting
memberdelay=1 as putnopvut suggested in bug 12771 has not removed the
problem.
Another symptom of the problem is delayed call presentation to an
available agent.
When this occurs core show channels will show SIP in use
show queues will show agent not in use
Waiting for the channel to free will fix the call presentation
soft hangup the busy channel will fix the call presentation
core show locks does not show any locks
I'm tracking progress of this issue on bugs 12771 12773 and 12916
I don't use channel agent so I am not adding notes to bug 12773 since it
is under category chan_agent and patch is for chan_agent
Currently I have issues on 1.4.21 using SIP QueueAddMember.
I use 1.4 backport of putnopvut's state_interface patch from *1.6 on
*1.4.21 but it is clear that this issue also effects *1.6 so I don't think
this is related.
My call centers cannot live with agent busy state until transferred call
is torn down so I must use the state_interface backport.
Issue History
Date Modified Username Field Change
======================================================================
07-04-08 07:58 aragon Note Added: 0089741
======================================================================
More information about the asterisk-bugs
mailing list