Multiple Agents Join Queues on Single Extension

[chemmerling]

Hello,

We are running QueueMetrics 14.03, and Asterisk 11.7.0 with Hot Desking enabled, and used by QueueMetrics.

We are running into an issue with agent queue joining overwriting other agent's joined queues with their login information if they use identical extensions.

While we would love to have everyone check the extension number they are putting in (and log in CORRECTLY), there is always the possibility of fat-fingering the extension number, and logging in to someone else's phone.

Chain of events:
1) Agent 101 logs in and joins queues 8000 and 8004 on extension 1555
2) Agent 101 pauses with a code (we'll use Lunch for this example) and walks away
2) Agent 201 logs in, and attempts to join queue 8000 on extension 1555
3) Realtime monitoring shows that agent 101 is still in the queues that they are assigned, and does not show Agent 201 logged in.
4) Agent 101 comes back from their "Lunch" and attempts to Unpause with no effect.
5) Agent 101 attempts to leave the queues with no effect:

Inside the agent page:
Agent 101 still shows logged in to the queue, even though they are not:
Active calls for agent Test 3
agent/101: Agent is currently paused (12: Lunch)

Inside Realtime Monitoring:
Agent 101 | 08/13 - 17:21:46 | 8000, 8004 | sip/1555 | 17:21 Lunch | | | |

6) Agent 101 must now join the queues (all assigned) in order to leave the queues, and is stuck in the Realtime Monitoring page inside QueueMetrics

We are looking for a way to keep agents from accidentally using an already used extension. This would prevent someone from causing QueueMetrics from overwriting who is on an extension already, causing us to have to re-add the agent, and then remove them from the queues.

This happens on 14.06 as well.

[chemmerling]

This happens on 14.06 as well.

[mirkox]

Hi,

in many cases this is the desired behaviour since many times agents forget to log off after their working session.

A solution for this problem could be to implement a script in the logon dialplan that checks if the extension is already used by an agent in that given moment (you can use QueueMetrics' API to get this information),

Mirko

[chemmerling]

Before I continue, I should mention that we are not using the new agent page. We are using the live_agent.jsp page because this prevents agents from adding or removing queues on the fly when they are assigned specific queues.

Additionally, not all agents are assigned the same queues. Agent 1 may have queues 8001 and 8002, while Agent 2 may have only 8002 and 8003. The situation leaves Agent 1 stuck in 8001 until someone takes steps to correct it.

in many cases this is the desired behaviour since many times agents forget to log off after their working session.

I don't see how this is desired behavior.

If two agents sit next to each other, and the first agent is already joined to queues in to Ext 1001, and the second agent accidentally uses Ext 1001 (instead of their own like 1002) to join queues it creates a complete mess for users to deal with. The corrections steps for this situation are:

1) Agent 1 needs to wait as Agent 2 leaves queues
2) Agent 2 needs to leave the queues
3) Agent 1 needs to rejoin queues

A supervisor has to:

1) Have Agent 2 leave the queues
2) Join the queues as Agent 1 at the extension in question
3) Leave the queues
4) Have Agent 2 join the queues again.

This puts customers on hold until the issue is resolved. Users should NOT have to re-add an agent to an extension just to remove them from QueueMetrics.

The truly desired behavior by us end users would be to remove the agent already logged in to the extension completely from both QueueMetrics and Asterisk, and not overwrite the agent that's there, leaving them in the realtime page still signed in, and unable to complete any functions.

Another real solution to the problem is what you mention below:

A solution for this problem could be to implement a script in the logon dialplan that checks if the extension is already used by an agent in that given moment (you can use QueueMetrics' API to get this information),

This is another correct solution. This should be integrated into the login process to check to see if the extension is already in use. If an agent logs in it truly shouldn't bump an agent that is already signed in.

It is the duty of the Supervisor to ensure that agents are logged out for the day. It shouldn't be up to the software to decide to leave an agent "logged in" (and ONLY in QueueMetrics), and allow the other agent to login on top of them.

I should also mention that this creates extreme problems with the New Agent Page in 14.06. I downloaded and have been testing this scenario. If you don't use live_agent.jsp OR the Realtime Monitoring page, you are UNABLE to fix this situation.


I apologize for any strong wording in this, but we have been fighting with this issue since Launch in January, and have been met with opposition to see the actual issue here. I don't know what more I can do to make it clear enough to understand.

[mirkox]

Hello,

Before I continue, I should mention that we are not using the new agent page. We are using the live_agent.jsp page because this prevents agents from adding or removing queues on the fly when they are assigned specific queues.

This was fixed and will be available in the next release (realtime.dynamicLoginQueues=assigned will only show assigned queues and will prevent the agent from logging in/out from single queues).

As for the main issue, we think this could be implemented (I created and entry in our bug tracker: #2457), but we don't have a schedule for this, surely won't be present in the next release. If you need it urgently you could think about a customization.

Kind Regards
Mirko

[chemmerling]

Thank you for your attention to the matter.

I believe that this is the only issue that would prevent me from suggesting QueueMetrics to anyone as an Out-of-the-box solution.

We've looked at getting this as a customized feature, but I believe we were told this is how it should work.

Thanks, also, for the info about the new agent page being updated for the next release. We will keep an eye out for it!