Mysterious 15 Seconds Between Dials

[benomg]

OK, so I've come here from a support section hoping to get to the bottom of this. It's not a support question really, possibly a bug. I'm not to big on what goes on in the depths of the VD scripts so I could be wrong but I'll explain what I'm seeing.

This is me calling 1111111111 (which is replacing an actual number) with the dial timeout at 10 seconds so the calls are going to NO ANSWER. Notice the 15 seconds between the end of one call and the next call. Can anyone please explain what happens after a NO ANSWER call?

"","0000000000","8368","default","""V0925113512000060204"" <0000000000>","Local/1111111111@default-6f57,1","","Dial","Local/1111111111@default","2009-09-25 11:35:22",,"2009-09-25 11:35:22",0,0,"FAILED","DOCUMENTATION"
"","0000000000","1111111111","default","""V0925113512000060204"" <0000000000>","Local/1111111111@default-6f57,2","IAX2/mytel-11139","Dial","IAX2/mytel/1111111111||tTor","2009-09-25 11:35:12",,"2009-09-25 11:35:22",10,0,"NO ANSWER","DOCUMENTATION"
"","0000000000","8368","default","""V0925113537000060205"" <0000000000>","Local/1111111111@default-ce71,1","","Dial","Local/1111111111@default","2009-09-25 11:35:47",,"2009-09-25 11:35:47",0,0,"FAILED","DOCUMENTATION"
"","0000000000","1111111111","default","""V0925113537000060205"" <0000000000>","Local/1111111111@default-ce71,2","IAX2/mytel-11941","Dial","IAX2/mytel/1111111111||tTor","2009-09-25 11:35:37",,"2009-09-25 11:35:47",10,0,"NO ANSWER","DOCUMENTATION"
"","0000000000","8368","default","""V0925113602000060206"" <0000000000>","Local/1111111111@default-552d,1","","Dial","Local/1111111111@default","2009-09-25 11:36:12",,"2009-09-25 11:36:12",0,0,"FAILED","DOCUMENTATION"
"","0000000000","1111111111","default","""V0925113602000060206"" <0000000000>","Local/1111111111@default-552d,2","IAX2/mytel-5430","Dial","IAX2/mytel/1111111111||tTor","2009-09-25 11:36:02",,"2009-09-25 11:36:12",10,0,"NO ANSWER","DOCUMENTATION"

This is the matching asterisk events on high v.

-- Executing AGI("Local/0290372846@default-6f57,2", "agi://127.0.0.1:4577/call_log") in new stack
-- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
-- Executing Dial("Local/1111111111@default-6f57,2", "IAX2/mytel/1111111111||tTor") in new stack
-- Called mytel/1111111111
-- Call accepted by 203.166.103.242 (format ulaw)
-- Format for call is ulaw
-- IAX2/mytel-11139 is ringing
-- Hungup 'IAX2/mytel-11139'
== Spawn extension (default, 1111111111, 2) exited non-zero on 'Local/1111111111@default-6f57,2'
-- Executing DeadAGI("Local/0290372846@default-6f57,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------") in new stack
== Manager 'sendcron' logged off from 127.0.0.1
-- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0
== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'sendcron' logged on from 127.0.0.1
-- Executing AGI("Local/1111111111@default-ce71,2", "agi://127.0.0.1:4577/call_log") in new stack
-- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
-- Executing Dial("Local/1111111111@default-ce71,2", "IAX2/mytel/1111111111||tTor") in new stack
-- Called mytel/1111111111
-- Call accepted by 203.166.103.242 (format ulaw)
-- Format for call is ulaw
-- IAX2/mytel-11941 is ringing
-- Hungup 'IAX2/mytel-11941'
== Spawn extension (default, 1111111111, 2) exited non-zero on 'Local/1111111111@default-ce71,2'
-- Executing DeadAGI("Local/1111111111@default-ce71,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------") in new stack
== Manager 'sendcron' logged off from 127.0.0.1
-- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0
== 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
== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'sendcron' logged on from 127.0.0.1
-- Executing AGI("Local/0290372846@default-552d,2", "agi://127.0.0.1:4577/call_log") in new stack
-- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
-- Executing Dial("Local/0290372846@default-552d,2", "IAX2/mytel/1111111111||tTor") in new stack
-- Called mytel/1111111111
-- Call accepted by 203.166.103.242 (format ulaw)
-- Format for call is ulaw
-- IAX2/mytel-5430 is ringing
== 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
-- Hungup 'IAX2/mytel-5430'
== Spawn extension (default, 1111111111, 2) exited non-zero on 'Local/1111111111@default-552d,2'
-- Executing DeadAGI("Local/0290372846@default-552d,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------") in new stack
== Manager 'sendcron' logged off from 127.0.0.1
-- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0

Just to answer any campaign questions...

campaign_id TESTCAMP
campaign_name TESTCAMP
active Y
dial_status_a
dial_status_b
dial_status_c
dial_status_d
dial_status_e
lead_order DOWN
park_ext
park_file_name
web_form_address
allow_closers Y
hopper_level 100
auto_dial_level 1
next_agent_call oldest_call_finish
local_call_time 24hours
voicemail_ext
dial_timeout 10
dial_prefix X
campaign_cid
campaign_vdad_exten 8368
campaign_rec_exten 8309
campaign_recording ONDEMAND
campaign_rec_filename FULLDATE_CUSTPHONE
campaign_script
get_call_launch WEBFORM
am_message_exten
amd_send_to_vmx N
xferconf_a_dtmf
xferconf_a_number
xferconf_b_dtmf
xferconf_b_number
alt_number_dialing N
scheduled_callbacks Y
lead_filter_id NONE
drop_call_seconds 5
drop_action MESSAGE
safe_harbor_exten 8307
display_dialable_count Y
wrapup_seconds 0
wrapup_message Wrapup Call
closer_campaigns
use_internal_dnc Y
allcalls_delay 0
omit_phone_code Y
dial_method RATIO
available_only_ratio_tally N
adaptive_dropped_percentage 3
adaptive_maximum_level 3.0
adaptive_latest_server_time 2100
adaptive_intensity 0
adaptive_dl_diff_target 0
concurrent_transfers AUTO
auto_alt_dial ALT_ONLY
auto_alt_dial_statuses B N NA DC -
agent_pause_codes_active Y
campaign_description Test campaign for ViciDial
campaign_changedate 2009-09-25 11:34:31
campaign_stats_refresh N
campaign_logindate 2009-09-25 11:36:15
dial_statuses NEW -
disable_alter_custdata N
no_hopper_leads_logins Y
list_order_mix DISABLED
campaign_allow_inbound Y
manual_dial_list_id 998
default_xfer_group ---NONE---
xfer_groups
queue_priority 50
drop_inbound_group ---NONE---
qc_enabled N
qc_statuses NULL
qc_lists NULL
qc_shift_id 24HRMIDNIGHT
qc_get_record_launch NONE
qc_show_recording Y
qc_web_form_address NULL
qc_script NULL
survey_first_audio_file US_pol_survey_hello
survey_dtmf_digits 1238
survey_ni_digit 8
survey_opt_in_audio_file US_pol_survey_transfer
survey_ni_audio_file US_thanks_no_contact
survey_method AGENT_XFER
survey_no_response_action OPTIN
survey_ni_status NI
survey_response_digit_map 1-DEMOCRAT|2-REPUBLICAN|3-INDEPENDANT|8-OPTOUT|X-NO RESPONSE|
survey_xfer_exten 8300
survey_camp_record_dir /home/survey
disable_alter_custphone Y
display_queue_count Y
manual_dial_filter NONE
agent_clipboard_copy NONE
agent_extended_alt_dial N
use_campaign_dnc N
three_way_call_cid CAMPAIGN
three_way_dial_prefix
web_form_target _blank
vtiger_search_category LEAD
vtiger_create_call_record Y
vtiger_create_lead_record Y
vtiger_screen_login Y
cpd_amd_action DISABLED
agent_allow_group_alias N
default_group_alias

[williamconley]

have you tried increasing the 10 second timeout to 25 to see if it increases your between time or not? (it could just be that the timeout has no effect on the next dialout ... would be interesting to see)

[benomg]

Yes, I have tried this at different timeout amounts, 25, 45, it is the same deal.

[williamconley]

So you are saying that no matter what you set your timeout to, no matter how many calls there are, there is always a 15 second "waiting period" after each call terminates before another call is generated?

Interesting. I don't think I've ever checked. What's your build number? Do you have any other software installed in your box? Straight Vicibox install?

[benomg]

I've only seen it for no answer calls. I've tested agent hang up and AMD hang up but that is fine, VD dials straight away.

What do you refer when you say build number? Is it in my signature?

I selected to install SSH during the ubuntu install, that's it.

[williamconley]

build number is listed on your vicidial admin screens (VERSION: 2.X.X-XXX BUILD: XXXX-XXXX)

i don't suppose you've tried this with a "DEMO CD" version to see if it persists ...?

[benomg]

Vicidial 2.0.5-173, Build 90320-0424.

I will try the demo as soon as I can.

[benomg]

Ok, I still haven't been able to run a demo, but I do have the same issue on 2 separate installs.

[benomg]

OK I don't know why but after a lot of poking around in the code and changing an amount of options to many to remember, it came down to one setting, the drop call seconds. Drop call seconds is "the number of seconds from the time the customer line is picked up until the call is considered a DROP, only applies to outbound calls". I didn't test if it did control this but what it did do when changed from 5 to 0 is cut that 15 seconds between calls on ratio when calls go to no answer to 0-1 seconds. I can can move that up and down and see the time after a no answer call change sort of with it (0 drop call seconds = 0 seconds between no answer and next call, while 5 drop call seconds = 15 seconds between calls).

[williamconley]

Now that is an interesting concept. Thanks for the information.

[phil_discount]

i checked it too, exactly the same problem...
drop timeout = 0 seconds, vici immidiatly dials out
drop timeout = 3 seconds, vici dials after 10 seconds
drop timeout = 5 secondy, vici dials after 15 seconds

regards
philip

[williamconley]

that's even more interesting

what happens with drop timeout at 0? no calls to agents?

what about drop timeout at 1?

[phil_discount]

i make a test and controlled the time:

drop timeout 60 - 70 seconds
drop timeout 30 - 70 seconds
drop timeout 20 - 30 seconds
drop timeout 10 - 20 seconds
drop timeout 5 - 13 seconds
drop timeout 0 - 3-4 seconds

very interesting or?

[williamconley]

what about drop timeout at 1?

i'd actually be very interested to see 0,1,2,3,4,5

[phil_discount]

timeout 1: after 11 seconds next call, then 5 seconds, 11 seconds again and 5 seconds so on... <- totally strange
timeout 2: after 12 seconds next call
timeout 3: after 13 seconds next call
timeout 4: after 14 seconds next call
timeout 5: after 15 seconds next call

[williamconley]

what kind of trunk is this again?

[phil_discount]

PRI E1 line, but now i was testing it with a SIP trunk too...same result

[williamconley]

have you tried this with a 2.2.0 or 2.4 system yet?

[phil_discount]

no i've got no 2.2.0 system because we use the vnow screen (modified) and the screen is not yet been ported to 2.2.0

EDIT:
i believe i found the error.
the call wil not be deleted from the database.
in realtime display i see that the call is still alive...
but the phone isn't ringing anymore.

regards
philip

[williamconley]

well i'd say that's likely. but it gets deleted ... by a process that runs Late. what makes it run late?

[phil_discount]

which script clears the vicidial_live_channels...must be depending to the drop timeout...

[phil_discount]

does the problem occur in 2.2.0 too?

[phil_discount]

i just installed 2.2.0 on a virtual machine.
the problem still occurs...if i delete the database entry of the call in vicidial_auto_calls, vici immediately calls the next customer. but i if i do that, the status of the lead still is NEW and no call-entry in vicidial_log.

any ideas or does it occur not on each vici installation?

regards
philip

[williamconley]

do you know of an installation on which it does not occur?

[phil_discount]

only 2.0.5 in production and now a test installation with 2.2.0

[williamconley]

i just installed 2.2.0 on a virtual machine.
the problem still occurs...

2.2.0 ... it occurs

do you know of an installation on which it does not occur?

only 2.0.5 in production and now a test installation with 2.2.0

2.2.0 and 2.0.5 it doesn't?

you are confusing me

[phil_discount]

sorry, i'm a german
the problem occurs on both, 2.2.0 and 2.0.5.

i never tried another version

[phil_discount]

now i tried it with Agent web-client version: 2.2.1-260 BUILD: 100527-2211

the problem still occurs.
is there nobody else with this problem? i think it's a major problem cause the productivity will decrease on every NA - No Answer Call?

[mflorell]

We have not had this problem reported by any of our clients that I know of.

[phil_discount]

perhaps they don't realize it because it's very tricky do find out.
in realtime display you don't see it, you realize it only if you have a testcampaign with one agent logged in..

[williamconley]

it is prevalent in 2.0.5 and 2.2.0 (i've not tested for it beyond that)

[mflorell]

I don't know that we have any clients running 1-agent auto-dialer campaigns. The predictive algorithm runs at a 15-second update schedule, but that's about the only thing that does. Not sure why that would be causing this issue though unless you were dialing available only tally, which I guess you should be with only one agent.

[williamconley]

so you are saying this issue is related to available only tally?

as in ... the system does not know for sure that those calls were terminated so it leaves them until they "clear"?

[phil_discount]

yes, that's right.
when i manually delete the record in database, vicidial instant dials the next customer, but then i've got no record in the call_log.

[williamconley]

if you turn off available only, does the behavior change?

[phil_discount]

same problem with available only ON, auto dialing with droprate is activated

[williamconley]

i asked if it happens when you turn available only tally OFF (you answered ON instead)

[phil_discount]

sorry, with both configurations the problem still exists.
i turned drop_seconds to 0 and so the problem doesn't occur...
not really fine but it works

[williamconley]

thanks for the postback. we've had a few inquiries, but as yet noone wants to pay to fix it. so unless we get some "free time" (right!) ... well, maybe i'll get curious one of these nights waiting for a compile or something

[dinstar]

Hello, I think I am facing same issue. My dailing speed for press 1 campiang with remote agent is half that of my older system.


Just one question, where can i change drop timeout rate???