[Home]

Summary:ASTERISK-12036: Device State stay stuck to "inuse" causing agent not to receive anymore call
Reporter:dimitripietro (dimitripietro)Labels:
Date Opened:2008-05-16 21:49:37Date Closed:2011-06-07 14:02:36
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) relevant_configs.txt
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.

****** ADDITIONAL INFORMATION ******

After the agent stop receiving call, even if is not on the phone, the device state of his phone stay to "inuse". By login and logout multiple time, some time it's seem to fix the issue but I'm not sure it's related.

Here is the "core show channnels" output while it's stuck :

Channel              Location             State   Application(Data)
SIP/216-0a232a20     (None)               Up      Bridged Call(Local/9022@agent-
Local/9022@agent-586 9022@agent:4         Up      Dial(SIP/216)
Local/9022@agent-586 open@agent:1         Up      Bridged Call(Zap/20-1)
Zap/20-1             s@macro-programEnter Up      Queue(XXXXXXXXXXX,t,,,420)
SIP/219-0a2636f0     (None)               Up      Bridged Call(Local/9010@agent-
Local/9010@agent-132 9010@agent:4         Up      Dial(SIP/219)
Local/9010@agent-132 open@agent:1         Up      Bridged Call(Zap/8-1)
Zap/1-1              (None)               Up      Bridged Call(SIP/223-b7ce92f8)
SIP/223-b7ce92f8     s@macro-dialOutbound Up      Dial(ZAP/g1/XXXXXXXXXX,,gT)
Zap/8-1              s@macro-programEnter Up      Queue(myXXXXXX,t,,,420
10 active channels
5 active calls
529 calls processed

As we can see, the agent is not on the phone anymore (agent 9009) but "queue show XXXXXXXXX" report the agent as in use (Remeber i'm using the new way to define device state lookup using addqueuemember state device argument

Local/9009@agent/n (dynamic) (In use) has taken no calls yet

And finally "core show hints" :

214@abc              : SIP/214               State:InUse           Watchers  0

I can provide any information necessary to resolv that issue.

Comments:By: ddkprog (ddkprog) 2008-05-19 14:39:23

try to reload queues
By: dimitripietro (dimitripietro) 2008-05-19 16:13:46

The problem "I think" have nothing to do with the queue because the device state of SIP/214 stay as "INUSE" nothing to do with app_queue himself
By: ddkprog (ddkprog) 2008-05-20 02:06:44

try to reload queue from console
By: dimitripietro (dimitripietro) 2008-05-20 06:46:17

K, Next time it happen I will. I use to happen a couple of time a day but i'm not always at the office.
By: dimitripietro (dimitripietro) 2008-05-21 08:24:40

I did reload but it didn,t solve the problem. The device is still inuse :

216@XXX              : SIP/216               State:InUse
By: Mark Michelson (mmichelson) 2008-05-21 14:45:42

The problem here is apparently that the SIP device's state is getting "stuck" in use. dmitripietro is correct that the problem is not related to app_queue, but actually SIP device state. I'm going to recategorize this to indicate that fact.

How easy is this to reproduce? Is there a reliable set of steps that can be taken to get this to occur or does it happen seemingly at random?
By: dimitripietro (dimitripietro) 2008-05-21 15:03:09

It's random but it's happening often. I would say more than 5 times a day.
By: David Brillert (aragon) 2008-05-28 11:55:56

I believe this issue was fixed in revision 116038
closes issue 12584
related to issue 12603

This bug should be closed?
By: dimitripietro (dimitripietro) 2008-05-28 12:06:01

I will try to update to the latest 1.6 branches
By: pj (pj) 2008-05-30 14:13:26

I was reported similar issue with phones stuck in "inuse" state some time ago, see bugreport 0011304, but oej closed it with this comment:
"issue seems like a bug, but there are several related bug reports here in the bug tracker. I think this is a duplicate bug report."

:-\
By: dimitripietro (dimitripietro) 2008-06-02 14:59:35

It's still happening,

asterisk*CLI> core show version
Asterisk SVN-branch-1.6.0-r118648 built by root @ asterisk.peopleclubs.com on a i686 running Linux on 2008-05-19 02:03:51 UTC
By: ptorres (ptorres) 2008-06-03 09:19:41

We had a couple of issues like this, one was caused by a bug in some version of x-lite that anwsered a sip:cancel (queue timeout while the softphone was ringing) with a trying and nothing else after that, which caused the device state to be 'in use' because the peer had a pending call  ( you can check this with "sip show inuse" )

The other was that state changes were delayed because of dns queries, details in 0012627 ( http://bugs.digium.com/view.php?id=12627 )

hope it helps :)
By: David Woolley (davidw) 2008-06-04 07:25:02

There seems to be a general problem that Asterisk can think that a call is up when the phone doesn't think so, or is even unplugged or powered down.  If you have inuse counts for presence, or because the phone is a direct member of a queue, the inuse count won't get decremented.  I think this is particularly true when Asterisk is one side of the call (AgentLogin and MusicOnHold, in our cases) as, with a human as the other party, they can clear the call from the other end.  Our problems have happened when a phone gets powered down overnight whilst still logged in as an agent, although it can also happen if you do that whilst on MusicOnHold.

One could argue that a qualify failure should bring down all calls, but there are cases where this might bring down an external bridge which was otherwise working quite happily.

Empirically, one can reset the inuse count by doing a SIP reload, but the fact that you can do that is itself a bug!

Note, if you have an agent logged in with AgentLogin, you do not need to have usage limits on the actual phone.  If you are getting the "still 'Not in Use'...see upgrade.txt" message, that is nothing to do with the SIP phone, but is actually a race condition in the handling of the agent.  See ASTERISK-12125.
By: Badalian Vyacheslav (slavon) 2008-06-04 08:16:39

I have some problem... if poweroff device sometime its stay INUSE... last see 1-2 weeks ago at fresh 1.4 SVN version
Queue members is static devices like Member => SIP/DeviceX


By: dimitripietro (dimitripietro) 2008-06-04 12:49:12

I'm using Addqueuemember in Asterisk 1.6 with the new device state options. The phone aren't rebooting. I'm using Polycom phone, no Xlite.
By: Mark Michelson (mmichelson) 2008-06-05 10:15:20

I started thinking about this, and I have a hypothesis of what's happening. I'm going to provide a patch to try testing.

What I think may be happening is similar to what was reported in issue ASTERISK-12073. I will have a patch soon to test.
By: Mark Michelson (mmichelson) 2008-06-05 10:17:59

Nope, it turns out I'm not right. I thought there was a shallow copy of string that needed to be replaced with a deep copy, but that is not the case. The problem is apparently happening somewhere else. Sorry about the false hope :(
By: pj (pj) 2008-06-05 11:39:58

can anyone try case, that makes 'inuse' issue in my environment...?
- verify, if you have callwaiting enabled on phone (more than one call per line)
- start one outbound call from sip phone
- make another incomming call to phone (ie. call will waiting on phone)
- hangup
- 'sip show inuse'
in my environment, this shows weird values like -1/0/0
on phones, that monitors affected line, displays that line as 'busy'
By: Tilghman Lesher (tilghman) 2008-06-19 17:29:16

Another question:  The agent that is marked in use, how was his last call ended?  With a hangup or a transfer?  Transfers are known not to end an agent as being marked in use, with respect to a queue.  Only when the call is hungup will the agent be once again available.
By: Tilghman Lesher (tilghman) 2008-07-02 15:04:12

I need a response or this issue will be closed.
By: dimitripietro (dimitripietro) 2008-07-02 18:53:14

I will give you feedback very shortly
By: David Brillert (aragon) 2008-07-04 07:58:56

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.
By: Tilghman Lesher (tilghman) 2008-07-14 16:30:53

aragon:  Please try current SVN 1.6.0, as issue ASTERISK-12127 has been committed and it sounds like the fix there may fix this issue.
By: David Brillert (aragon) 2008-07-29 07:35:16

We have been using patch from 12771 and no longer experience delays in state change or device stuck "in use" causing agent not to receive calls.
IMHO this ticket is related to bug 12771
By: Tilghman Lesher (tilghman) 2008-07-29 08:54:04

Looks like this one has been fixed with the combination of fixes in ASTERISK-12125 and ASTERISK-12127