Queue Crosstalk/Jumping

An unusual issue came up on a production system today where the client reported that the callers were coming through on the wrong queue (which was an issue as the queues are for two separate companies).

After checking everything in relation to the call flow, could not understand how it was occurring as everything was checked and rechecked and then another person checked and rechecked.

Finally the we located the issue and feel that it should be listed as a Bug as it did and could happen again. We recognise that it would be a rare event but it did and will happen again.

We have two Queues
Numbered 20 & 40 (historical reasons)
The Extensions are numbered 400 through to 420
The agents for the Queues dynamically log into the Queue(s).

The cause of the issue was that one of the users on extension 404, at sometime, tried to log themselves on Queue 20, and instead of typing the Agent number of 404, they have mistyped and ended up with 40. They soon realise that they are not getting calls and relog themselves back on the queue, however there is an Agent 40 in the queue. It presents other issues such as the queue never being empty, but not as major as the issue with the Queues.

If an external call comes in on Queue 20, after music on hold is played the call actually flicks onto the Queue 40 every time. This issue is reproducible. It would not be a major issue if just upset things for that one agent, but it doesn't, it throws things out for all calls to the Queue 20, in effect crippling the business.

I have included a copy of the relevant lines of the full file for review.

{noformat}
logger.c: – Executing [20@ext-queues:18] Set("Zap/9-1", "__MOHCLASS=default") in new stack
logger.c: – Executing [20@ext-queues:19] Queue("Zap/9-1", "20|t|||20") in new stack
logger.c: – Started music on hold, class 'default', on Zap/9-1
logger.c: – Called Local/40@from-internal/n
logger.c: – Executing [40@from-internal:1] Macro("Local/40@from-internal-9521,2", "user-callerid|"){noformat}

To confirm this was an issue, the rogue agent was logged off and queue operation returned to normal.

Not sure if this can be corrected programatically, but thought it should be raised.

I can provide more of the log if required but the rest shows it moving along the Queue 40