Queues: Too many Calls in queue crash Asterisk.

If you’ve ever had problems where high calls in queue crash asterisk, or if too many calls in queue spike cpu usage, then you may have problems with erroneous agents logged into the queue.  This article applies to Asterisk 11.0.1 and 11.2.1. It may apply to others but that is not implied or guaranteed 😉

Freepbx can appear to go unstable after more than 5 or 6 calls go into the queue, even on a fast system. The most apparent reason for this is agents that are left in the queue.

If you have a medium to large size organization, or even if you just grow often, you will move your agents. And if agents move and they are not properly logged out, then they may never get logged out.

FreePbx configures asterisk in such a way that when an agent logs in, it’s member id becomes a fairly long complicated string, like “Local/123@from-queue/n”. This is the same string needed to modify it’s position. Now when an agent logs out, it deletes that string. But sometimes people don’t keep the same extension, or some unforeseen variable changes the outcome of the id hashing algorithm and that agent won’t be removed. In this case, check out what happens:

Queue shows 10 agents logged in. 7 people are on the phone, 3 are actually not even online. Asterisks knows agents can take calls, and these people are in queue, so it sends calls to the queue. It can actually get stuck in a near-infinite loop: it sends the calls in queue to the agents who are offline (but logged in), and it loops around trying to send each call to each agent, everyone else is on the phone, so it keeps trying these 3 agents, as you can see, it will go as fast as your CPU can, so it’s equally destructive to high-power machines as on low-performance ones.

Personally, I think asterisk should be smart enough not to let this crash the system, but it’s the only explanation that makes sense. Log entries correspond with the queue repeatedly trying to send calls to sip locations that cannot be reached. The cure is to make sure your agents know to log out, but even with good managers this doesn’t always happen, so what is your recourse?

Well, if this becomes an ongoing problem, you might want to consider putting a Max on the number of calls in the queue, so that additional calls will failover to a voicemail or other system.

Alternatively, you can disable persistent queues, from the Advanced settings in freepbx, but on my version, it wouldn’t save the change, so I came up with just clearing the AstDB of PersistentMembers, essentially logging-out everyone. This can be done from CLI with “database deltree Queue”, or shell with # asterisk -rx “database deltree Queue”

The best solution is you can ensure that to your best ability, asterisk doesn’t try and send calls to extensions that don’t exist, but that’s a bit more complicated and for a future article.

If you have encountered this or a similar problem, please comment about it, and we can discuss. Also, a forum is coming soon!