Queue failover problem?

Using Asterisk 1.4.9, and loaded the latest modules recently.

We had a slight power problem in our office where the extension that was logged into the queue went offline. So the system still thinks that the agent is still logged in.

Calls come into the queue, but instead of going to failover Ring Groups as it normally does when a call is not answered in time, or is in the queue for too long, I get MOH, and then hangup.

After all of the power was all sorted and system, running as per normal, I got our recptionist to pull the LAN cable form her phone.

Same thing.

queue_additional.conf as follows

[1000]
announce-frequency=90
timeout=30
strategy=ringall
retry=5
queue-youarenext=
queue-thereare=
queue-thankyou=queue-thankyou
queue-callswaiting=
music=default
monitor-join=yes
monitor-format=
maxlen=1
leavewhenempty=yes
joinempty=no
eventwhencalled=yes
eventmemberstatus=no
context=
announce-holdtime=no
wrapuptime=5

CLI output as follows:

dialparties.agi: Caller ID name is ‘Queue:Bega Office’ number is '0264916491’
dialparties.agi: Methodology of ring is ‘none’
– dialparties.agi: Added extension 300 to extension map
– dialparties.agi: Extension 300 cf is disabled
– dialparties.agi: Extension 300 do not disturb is disabled
– dialparties.agi: dbset CALLTRACE/300 to 0264916491
== Manager ‘admin’ logged off from 127.0.0.1
– AGI Script dialparties.agi completed, returning 0
– Executing [[email protected]:10] Dial(“Local/[email protected],2”, “SIP/300|30|trwM(auto-blkvm)”) in new stack
== Everyone is busy/congested at this time (1:0/0/1)
– Executing [[email protected]:11] Set(“Local/[email protected],2”, “DIALSTATUS=CHANUNAVAIL”) in new stack
– Executing [[email protected]:10] Set(“Local/[email protected],2”, “SV_DIALSTATUS=CHANUNAVAIL”) in new stack
– Executing [[email protected]:11] GosubIf(“Local/[email protected],2”, “0?docfu|1”) in new stack
– Executing [[email protected]:12] GosubIf(“Local/[email protected],2”, “0?docfb|1”) in new stack
– Executing [[email protected]:13] Set(“Local/[email protected],2”, “DIALSTATUS=CHANUNAVAIL”) in new stack
– Executing [[email protected]:14] NoOp(“Local/[email protected],2”, “Voicemail is 300”) in new stack
– Executing [[email protected]:15] GotoIf(“Local/[email protected],2”, “0?s-CHANUNAVAIL|1”) in new stack
– Executing [[email protected]:16] NoOp(“Local/[email protected],2”, “Sending to Voicemail box 300”) in new stack
– Executing [[email protected]:17] Macro(“Local/[email protected],2”, “vm|300|CHANUNAVAIL”) in new stack
– Executing [[email protected]:1] Macro(“Local/[email protected],2”, “user-callerid|SKIPTTL”) in new stack
– Executing [[email protected]:1] NoOp(“Local/[email protected],2”, “user-callerid: Queue:Bega Office 0264916491”) in new stack
– Executing [[email protected]:2] Set(“Local/[email protected],2”, “AMPUSER=0264916491”) in new stack
– Executing [[email protected]:3] GotoIf(“Local/[email protected],2”, “1?report”) in new stack
– Goto (macro-user-callerid,s,13)
– Executing [[email protected]:13] NoOp(“Local/[email protected],2”, “TTL: 63 ARG1: SKIPTTL”) in new stack
– Executing [[email protected]:14] GotoIf(“Local/[email protected],2”, “1?continue”) in new stack
– Goto (macro-user-callerid,s,23)
– Executing [[email protected]:23] NoOp(“Local/[email protected],2”, “Using CallerID “Queue:Bega Office” <0264916491>”) in new stack
– Executing [[email protected]:2] Set(“Local/[email protected],2”, “VMGAIN=”) in new stack
– Executing [[email protected]:3] GotoIf(“Local/[email protected],2”, “0?vmx|1”) in new stack
– Executing [[email protected]:4] NoOp(“Local/[email protected],2”, "CAME FROM: 1000 - Blocking VM cause of key: ") in new stack
– Executing [[email protected]:3] Hangup(“Local/[email protected],2”, “”) in new stack
== Spawn extension (from-internal, 300, 3) exited non-zero on ‘Local/[email protected],2’
– Executing [[email protected]:1] Macro(“Local/[email protected],2”, “hangupcall”) in new stack
– Executing [[email protected]:1] ResetCDR(“Local/[email protected],2”, “w”) in new stack
– Executing [[email protected]:2] NoCDR(“Local/[email protected],2”, “”) in new stack
– Executing [[email protected]:3] GotoIf(“Local/[email protected],2”, “1?skiprg”) in new stack
– Goto (macro-hangupcall,s,6)
– Executing [[email protected]:6] GotoIf(“Local/[email protected],2”, “1?skipblkvm”) in new stack
– Goto (macro-hangupcall,s,9)
– Executing [[email protected]:9] GotoIf(“Local/[email protected],2”, “1?theend”) in new stack
– Goto (macro-hangupcall,s,11)
– Executing [[email protected]:11] Hangup(“Local/[email protected],2”, “”) in new stack
== Spawn extension (macro-hangupcall, s, 11) exited non-zero on ‘Local/[email protected],2’ in macro ‘hangupcall’
== Spawn extension (macro-hangupcall, s, 11) exited non-zero on ‘Local/[email protected],2’
– Nobody picked up in 0 ms
– Stopped music on hold on mISDN/3-u4
== Spawn extension (ext-queues, 1000, 18) exited non-zero on ‘mISDN/3-u4’

Not sure if this is technically a Beta issue, but thought it would be a good place to start.

Any hints are most appreciated.

from a very quick glance, the cli trace you showed here looked normal. A call in the queue was directed at extension 300, went to their phone and was blocked form voicemail - which would imply that the subsequent behavior would be how ever your queue handles things.

p

Should the subsequent behavior be Failover to the Ring Groups if the 300 extension is unavailable all of a sudden. The normal failover works fine while the phone is actually working.

But kill the ethernet on the extension, should mean that , call cannot be connected to 300, pass call to Failover Ring Group, and not just hang up.

300 is the only agent logged in normally. If that phone goes offline for any reason, how should I have my queue configured to go to failover ring group.

I have leaveempty=yes, and joinempty=no.

Any further help is much appreciated. I don’t want to have our callers getting hung up just because the reception phone has a sudden technical problem while it is logged in the queue.

for starters, if this is a production system, I wouldn’t be running Asterisk 1.4 if it were my system, and you should test the behavior on 1.2 to see if this is a 1.4 issue. As far as setup - I would normally setup queues with a max wait time.

From what you describe it sounds more like an Asterisk bug (and queues have not changed on FreePBX 2.3). You should switch to Asterisk 1.2 and see what the behavior is there.