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