[asterisk-users] queue member state

[Mark Michelson]

Rilawich Ango wrote:
> I have a realtime queue and the state of the queue member change as
> below.  Not-in-use (no call)-> Unknown (ringing)-> Not-in-use
> (answered).  The state shown in "show queues" does not really reflect
> the state of the phone.  I have searched the net and also the
> UPGRADE.TXT by the warning message below.  I follow the setting in
> UPGRADE.TXT to set the call-limit for each user from value 1 - 10 but
> the state keeps changing as below.
> 
> Anyone can tell me what kind of setting is necessary to reflect the
> state of the phone in queue?
> 
> --no call--
> 2200         has 0 calls (max unlimited) in 'rrmemory' strategy (3s
> holdtime), W:0, C:0, A:0, SL:0.0% within 120s
>    Members: *CLI>
>       Local/2003 at sipauth (dynamic) (Not in use) has taken no calls yet
>    No Callers
> 
> --a call in queue--
> 2200         has 1 calls (max unlimited) in 'rrmemory' strategy (3s
> holdtime), W:0, C:1, A:0, SL:100.0% within 120s
>    Members:
>       Local/2003 at sipauth (dynamic) (Unknown) has taken 1 calls (last
> was 7 secs ago)
>    Callers:
>       1. SIP/2002-02c68200 (wait: 0:04, prio: 0)
> 
> --call is answered--
> [Jul  7 18:09:57] WARNING[30371]: app_queue.c:3023 try_calling: The
> device state of this queue member, Local/2003 at sipauth, is still 'Not
> in Use' when it probably should not be! Please check UPGRADE.txt for
> correct configuration settings.
>   == Begin MixMonitor Recording SIP/2002-02c68200
> ivrdevserver*CLI> queue show
> 2200         has 0 calls (max unlimited) in 'rrmemory' strategy (10s
> holdtime), W:0, C:1, A:0, SL:100.0% within 120s
>    Members: *CLI>
>       Local/2003 at sipauth (dynamic) (Not in use) has taken 1 calls
> (last was 87 secs ago)
>    No Callers
> 

This is because Local channels are unable to report a device state once a call 
is bridged. This is because the Local channel "optimizes" itself out of the call 
path. If you want to get more accurate device state reporting for queue members 
and you need to use Local channels, then you can add /n to the end of the 
interface name for the queue member. This will cause the Local channel to not 
optimize itself out.

There is a known problem associated with the use of /n with a Local channel 
though. If your queue member transfers a call, then that queue member will be 
unable to receive a call from the queue until after the person that the queue 
member transferred the call to hangs up.

Mark Michelson