Agents stays logged in when phone goes offline

Asterisk Asterisk Support
1

We have a small call center and are trying to use Asterisk queues. We have configured two queues and agents, our operators log in via AgentLogin() application and all works fine.

But sometimes when operators SIP-phone goes offline or operator logs off, Asterisk doesn’t change agent status to “offline”. As a result, operators cant login for next time and we have wrong statistics of their worktime.

I’ve tried playing with persistentagents/autologoffunavail options but with no result. Normally, I use CLI command ‘agent logoff’ to log out agent manually, but even it doesn’t help sometimes. So I think it’s a bug.

Any suggestions?

2

How about running a script with a cron job that checks to see if the phones are available. If they are not to log them off. You can also tell them that they must log off when they leave or they are penalized. The latter seems to work pretty well.

3

I have done some tests, so let me explain the situation again.

The main problem is that Asterisk doesn’t change agent status when his SIP-session has ended incorrectly (soft-phone crashed, office switch rebooted).

So if agent logs in and then kills his 3CX-phone program with Task Manager, Asterisk will still connects callers with that agent. As a result, callers listen to silence for a while and then have to hang up a call.

Is it a bug? If not, how can I prevent this behavior?

4

Use qualify

5

What I should use it for? Currently I use ‘quality=yes’ (static, not realtime) and see messages like

when operator goes offline because of some hardware problems. But agent linked with peer 201 is still ‘logged in’.

6

There were bugs in device state handling for queue members some time ago, but they should be fixed in current versions. Which version are you using?

7

The version from digium rpm repo:

8

Might be a new bug then. Can I just confirm that there are no Local channels between the agent and the queue.

9

It’s very easy to verify the problem. Here’s my configs (just installed Asterisk from repository).

sip.conf:

15:35:32 root#beast[1]~>grep -v '\(;.*\|^$\)' /etc/asterisk/sip.conf [general] [authentication] [def](!) secret=pass context=default host=dynamic type=friend qualify=yes [201](def) username=201 [202](def) username=202 [203](def) username=203

agents.conf:

15:35:38 root#beast[1]~>grep -v '\(;.*\|^$\)' /etc/asterisk/agents.conf [general] persistentagents=no [agents] agent => 1,1,Will Meadows agent => 2,2,Will Meadows

queues.conf:

15:37:08 root#beast[1]~>grep -v '\(;.*\|^$\)' /etc/asterisk/queues.conf [general] persistentmembers = no autofill = yes monitor-type = MixMonitor shared_lastcall=no [test] strategy = rrmemory member => Agent/1 member => Agent/2

extensions.ael:

15:37:10 root#beast[1]~>grep -v '\(;.*\|^$\)' /etc/asterisk/extensions.ael globals { context default { 888 => { } 22 => { } }

Starting the test:

Loggin in:

Breaking SIP-connection:

[quote]beast*CLI>
[May 27 15:53:25] NOTICE[20305]: chan_sip.c:22850 sip_poke_noanswer: Peer ‘201’ is now UNREACHABLE! Last qualify: 101

beast*CLI> sip show peers
Name/username Host Dyn Nat ACL Port Status
201/201 194.50.85.84 D 20312 UNREACHABLE
[/quote]

The SIP-connection is broken now but Agent/1 is still active:

[quote]beast*CLI> agent show
[color=#FF0000]1 (Will Meadows) logged in on SIP/201-00000001 is idle (musiconhold is ‘default’)[/color]
2 (Will Meadows) not logged in (musiconhold is ‘default’)
2 agents configured [1 online , 1 offline]

beast*CLI> queue show
test has 0 calls (max unlimited) in ‘rrmemory’ strategy (0s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0% within 0s
Members:
Agent/2 (Invalid) has taken no calls yet
[color=#FF0000] Agent/1 (Not in use) has taken no calls yet[/color]
No Callers
[/quote]

And “serves” (!) calls:

That’s the situation. Any suggestions?

10

Check for existing reports on issues.asterisk.org/, and, if none, raise a new issue.

11

Have found a solution.

It’s not a bug, but a limitation of SIP protocol. Detailed answer is here. Without going into much detail, rtptimeout option may be used.

12

He’s using qualify, which does ensure that there is regular SIP traffice, to allow the connection loss to be detected. He has also confirmed that the connection loss IS being detected, just not actioned by app_queue.c.