We have an odd problem with our queue failover behaviour. We have four static agents in our queue, which has a failover destination to a ring group. Sometimes, the behaviour seems to change, in that after entering the queue, calls go straight to the failover destination without first ringing the queue’s agents. The only way we can get it back to normal is by performing a reload.
It seems that the glitch may be triggered when a call legitimately goes to the failover destination. It’s as though this initial failover call is taking the static agents out of the queue. We haven’t yet confirmed that that’s what is triggering it.
Any advice on what may be causing such behaviour would be appreciated.
Regards
We have FreePBX, so we’ve only performed reloads via that as yet, so I’m guessing that reloads everything. Next time it happens, I’ll try the app_queue reload.
I also need to run a show queue to confirm that it’s actually removing the static agents next time. Based on the fact that they return upon reload, I’m assuming that that’s what’s happening though.
That runs once an hour, which works for us. I’ve never been too exciting about the queueing in Asterisk and have actually written my own queueing application in extensions.conf and func_odbc - which may be a bit more involved than FreePBX allows. So far it’s working fine, but I haven’t rolled out the custom queueing to the whole office, yet. I enjoy re-inventing the wheel.
When I do a show queues normally, they do show up. I have not yet tried it when the issue is occurring. I have to wait until it occurs again before I can try.
I’m relatively new to the world of VOIP and Asterisk, so I wouldn’t really even know where to begin to set the members up as SIP or IAX channels, but I’ll look into it.
We experienced the problem again, and I can confirm that running module reload app_queue worked in getting things back on track.
Ian,
I ran the show queues command, and the queue still had all of it’s static members, so my assumption that they were being removed was incorrect. However, they were all invalid. Normally, they have a status of active or not in use, but when this problem occurred, they had a status of invalid
We seem to have worked out what’s causing this problem… sort of.
We use Pika Fax which is supposed to allow a fax to be sent to each users direct number, which will then send the fax to the users email address. Looking at the logs, it seems that when after (or during) a fax has been processed by Pika, Asterisk stops and restarts. I happened to be running a cli trace at the same time and noticed that the queue calls were referencing some ZOMBIE state. When I ran the show queue command, the queue members had a status of invalid.
I don’t know why Pika is causing asterisk to stop and start again, and I don’t know why the queue gets set to an invalid (zombie) state as a result.