[asterisk-bugs] [Asterisk 0012773]: [patch] Agent doesn't propagate device state changes from underlying device.

noreply at bugs.digium.com noreply at bugs.digium.com
Thu Jun 26 10:07:11 CDT 2008


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12773 
====================================================================== 
Reported By:                davidw
Assigned To:                Corydon76
====================================================================== 
Project:                    Asterisk
Issue ID:                   12773
Category:                   Channels/chan_agent
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     ready for testing
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 11:30 CDT
Last Modified:              06-26-2008 10:06 CDT
====================================================================== 
Summary:                    [patch] Agent doesn't propagate device state changes
from underlying device.
Description: 
Given a SIP phone logged in with AgentLogin, and monitored with qualify, if
you remove the power on the phone (or, presumably, unplug it from the
network) Asterisk detects that the phone has become unavailable, but the
agent continues to receive calls, resulting in callers going into a black
hole.

Ideally, I believe that the agent should detect the state change on the
underlying device and change its own state to logged off, and therefore
generate a state change to CHANUNVAIL.  This would result in correct
hinting for the agent's state.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
has duplicate       0012771 Bogus <member> is still 'Not in U...
====================================================================== 

---------------------------------------------------------------------- 
 davidw - 06-26-08 10:06  
---------------------------------------------------------------------- 
Inherited status having precedence means that, after the connection
recovers, the queue member status is stuck at "not in use", even though the
agent is actually busy.  I think this would cause problems if there were
multiple incoming queues.  In the following example, the queues are
manipulated in ways that make it difficult or impossible to create eligible
calls on multiple queues, so I can only demonstrate the status.  Our use of
paused is unusual; it might be preventing our getting problems when a
second call arrives, even with one real incoming queue - there is only one
call in these examples.

The queue names have been changed.  The third queue is the one for which a
call is actually being handled.

First a control.  Busy on one call before the phone went down.  Note
queues show busy.

AAAAAAAAAAAA has 0 calls (max unlimited) in 'rrmemory' strategy (0s
holdtime), W:1, C:0, A:0, SL:0.0% within 0s
   Members: I> 
      Anonymous (paused) (Busy) has taken no calls yet
   No Callers> 
localhost*CLI> 
BBBBBBBBBBBB has 0 calls (max unlimited) in 'rrmemory' strategy (0s
holdtime), W:2, C:0, A:0, SL:0.0% within 0s
   Members: I> 
      Anonymous (Busy) has taken no calls yet
   No Callers> 
localhost*CLI> 
CCCCCCCCCCCC has 0 calls (max unlimited) in 'rrmemory' strategy (11s
holdtime), W:0, C:6, A:0, SL:16.7% within 0s
   Members: I> 
      Anonymous (paused) (Busy) has taken 6 calls (last was 6392 secs
ago)
   No Callers> 

agent show reports:

logged in on SIP/4222-09ad1ad8 talking to ..... (musiconhold is
'default')

After disconnecting and reconnecting the phone, the queues are showing the
agent as not in use, even though there is a call active on the third
queue.

localhost*CLI> queue show
AAAAAAAAAAAA has 0 calls (max unlimited) in 'rrmemory' strategy (0s
holdtime), W:1, C:0, A:0, SL:0.0% within 0s
   Members: I> 
      Anonymous (paused) (Not in use) has taken no calls yet
   No Callers> 
localhost*CLI> 
BBBBBBBBBBBB has 0 calls (max unlimited) in 'rrmemory' strategy (0s
holdtime), W:2, C:0, A:0, SL:0.0% within 0s
   Members: I> 
      Anonymous (Not in use) has taken no calls yet
   No Callers

CCCCCCCCCCC has 0 calls (max unlimited) in 'rrmemory' strategy (8s
holdtime), W:0, C:7, A:0, SL:14.3% within 0s
   Members: 
      Anonymous (paused) (Not in use) has taken 7 calls (last was 83 secs
ago)
   No Callers

logged in on SIP/4222-09ad1ad8 talking to ...... (musiconhold is
'default')

All the devicestate changes for the agent, after the phone comes back,
give a not in use state (until the phone goes unreachable again, but that's
a different issue).

[Jun 26 14:47:00] DEBUG[16601] devicestate.c: Changing state for SIP/4222
- stat
e 5 (Unavailable)
[Jun 26 14:47:00] DEBUG[16601] devicestate.c: Notification of state change
to be
 queued on device/channel Agent/1001
[Jun 26 14:47:00] DEBUG[16601] devicestate.c: Changing state for
Agent/1001 - st
ate 5 (Unavailable)
[Jun 26 14:47:10] DEBUG[16621] devicestate.c: Notification of state change
to be
 queued on device/channel SIP/4222
[Jun 26 14:47:10] DEBUG[16601] devicestate.c: Changing state for SIP/4222
- state 1 (Not in use)
[Jun 26 14:47:10] DEBUG[16601] devicestate.c: Notification of state change
to be queued on device/channel Agent/1001
[Jun 26 14:47:10] DEBUG[16601] devicestate.c: Changing state for
Agent/1001 - state 1 (Not in use)

 Call answered here

[Jun 26 14:47:29] DEBUG[19792] devicestate.c: Notification of state change
to be queued on device/channel Agent/1001
[Jun 26 14:47:29] DEBUG[16601] devicestate.c: Changing state for
Agent/1001 - state 1 (Not in use) 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-26-08 10:06  davidw         Note Added: 0089279                          
======================================================================




More information about the asterisk-bugs mailing list