Delay, if outbound call is not answered, between calls.
Posted: Mon Jan 28, 2008 9:16 pm
Hey guys,
I noticed a small issue that I can't seem to remedy.
It seems that when vici is dialing out and if the other end timedout before the call was answered (or bad number or fast busy) that vici won't hang up and start to call another lead right away. There seems to be about a 2 minute delay between calls if this happens.
I can even check the "Real time" screen for the campaign when this happens and it says that a "call is being placed" when it actually was hung up.
Here is log of what happens in asterisk's console when this happens.
== Manager 'sendcron' logged on from 127.0.0.1
-- Executing [109316484771@default:1] Dial("Local/109316484771@default-b929,2", "Zap/g1/59316484771||tTo") in new stack
-- Requested transfer capability: 0x00 - SPEECH
-- Called g1/59316484771
-- Zap/1-1 is proceeding passing it to Local/109316484771@default-b929,2
-- Zap/1-1 is ringing
== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'sendcron' logged on from 127.0.0.1
== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'sendcron' logged on from 127.0.0.1
== Manager 'sendcron' logged off from 127.0.0.1
== Manager 'sendcron' logged off from 127.0.0.1
== Manager 'sendcron' logged off from 127.0.0.1
-- Hungup 'Zap/1-1'
== Spawn extension (default, 109316484771, 1) exited non-zero on
-- Executing [h@default:1] DeadAGI("Local/109316484771@default-b929,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------)") in new stack
-- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ----------) completed, returning 0
As you can see it first hangs up 'Zap/1-1' then executes the "h" extension. However, from this point it takes about 2 minutes for the next call to take place.
I am running vicidialer/astguiclient 2.0.4 with asterisk 1.4.xx.
I based my config from docs/extensions.conf.sample-1.4
Any suggestions?
Again, if the call is answered and the user hits "hang up" from the vici dial client, this does not apply. It will place the next call right away. It's only if a call is _not_ answered it pauses like that.
I noticed a small issue that I can't seem to remedy.
It seems that when vici is dialing out and if the other end timedout before the call was answered (or bad number or fast busy) that vici won't hang up and start to call another lead right away. There seems to be about a 2 minute delay between calls if this happens.
I can even check the "Real time" screen for the campaign when this happens and it says that a "call is being placed" when it actually was hung up.
Here is log of what happens in asterisk's console when this happens.
== Manager 'sendcron' logged on from 127.0.0.1
-- Executing [109316484771@default:1] Dial("Local/109316484771@default-b929,2", "Zap/g1/59316484771||tTo") in new stack
-- Requested transfer capability: 0x00 - SPEECH
-- Called g1/59316484771
-- Zap/1-1 is proceeding passing it to Local/109316484771@default-b929,2
-- Zap/1-1 is ringing
== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'sendcron' logged on from 127.0.0.1
== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'sendcron' logged on from 127.0.0.1
== Manager 'sendcron' logged off from 127.0.0.1
== Manager 'sendcron' logged off from 127.0.0.1
== Manager 'sendcron' logged off from 127.0.0.1
-- Hungup 'Zap/1-1'
== Spawn extension (default, 109316484771, 1) exited non-zero on
-- Executing [h@default:1] DeadAGI("Local/109316484771@default-b929,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------)") in new stack
-- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ----------) completed, returning 0
As you can see it first hangs up 'Zap/1-1' then executes the "h" extension. However, from this point it takes about 2 minutes for the next call to take place.
I am running vicidialer/astguiclient 2.0.4 with asterisk 1.4.xx.
I based my config from docs/extensions.conf.sample-1.4
Any suggestions?
Again, if the call is answered and the user hits "hang up" from the vici dial client, this does not apply. It will place the next call right away. It's only if a call is _not_ answered it pauses like that.