vicidial timeouts not quite working

[chrisbIT]

Hi all,

I seem to be having a problem with the vicidial/asterisk timeouts. We have a campaign set up on ratio dialing on level 1 so it only dials when agents are free. The timeout has been set to 25s. vici/asterisk place the call correctly and asterisk stops ringing the number after what seems about the correct time, however while watching the live time on VDAD the call still shows as continuing to ring and vicidial/asterisk does not place another call until about a minute or so has passed.

Does anyone have any ideas of how to get it to dial the next number straight away?

many thanks.

Chris

[brown078]

Hello,
Ive seen this issue when I didn't have the call_log.agi before each Dial() for outbound and the transfer (8655) section.

Please verify that you have that in your extensions.conf. Then check the timeouts.

[chrisbIT]

Thanks for the pointers. I did have the agi bits in the right places, but I had a simplified version as per the pdf astguiclient install manual on the wiki. So i changed it to match that of the scratch install, I also noticed the absence of:

Code: Select all

##### This 'h' exten is VERY important for VICIDIAL usage,
##### you will have problems if it is not in your dialplan!
exten => h,1,DeadAGI(agi://127.0.0.1:4577/call_log)
exten => h,2,DeadAGI(agi://127.0.0.1:4577/VD_hangup--HVcauses--PRI-----NODEBUG-----${HANGUPCAUSE}-----${DIALSTATUS}-----${DIALEDTIME}-----${ANSWEREDTIME}))


so I added that and tried again, this time I noticed complaints in the asterisk console regarding AGI scripts, so I dug about on the forums and found the tip about running the Fastagi script from the command line. This highlighted the missing perl module Net::Server (this bit is missing in the cpan part of the pdf guide by S Naresh Ananth Jois). So after adding this and watching the console I see the Agi script executing without complaint, but alas the original timeout issue remains

To double check I have created a test campaign with test leads that ring the phone on my desk. After the phone rings for the correct time, asterisk hangs up, the deadagi script executes returning 0 (success I presume) but 1 -3 minutes pass before vicidial vdad report decides to stop showing 1 call ringing and the next call gets placed. Is this normal behaviour thats hard coded somewhere, or is it likely something is not set right and it should be dialling straight away?

Many thanks in advance.

Chris

[mflorell]

That's the "h" exten entries that you need, but you also need the call_log running before you place an outbound call(like in the 91NXXNXXXXXX exten).

[chrisbIT]

Yes that is how I have it.

Is this normal behaviour from the dialler or should it start dialling as soon as one call has failed/timedout?

Thanks

Chris

[mflorell]

The dialer should dial another call once the attempted call is hung up or is terminated.

[mindseeker]

Yeah i have same issue also..but for me.. it takes 3 - 6 minute till asterisk put another call

[rajeevpn]

1. Is the database on a different server? In which case, do you have NTP setup to sync to the same time server and running periodically?

2. If you do, make sure that your cron entries are correct.

3. Your logs (that usually reside) in /var/log/astguiclient will also tell you when the Originate, Hangup commands were sent to the server

[chrisbIT]

Hi Rajeev,

The setup is all on one box.
This is a chunk from the asterisk CLI when making the call:

Code: Select all

 -- Executing AGI("Local/901142231278@default-48b3,2", "AGI(agi://127.0.0.1:4577/call_log") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/AGI(agi://127.0.0.1:4577/call_log
    -- AGI Script AGI(agi://127.0.0.1:4577/call_log completed, returning 0
    -- Executing Dial("Local/901142231278@default-48b3,2", "SIP/01142231278@10.1.0.100|50|tTo") in new stack
    -- Called 01142231278@10.1.0.100
    -- SIP/10.1.0.100-b44053a0 is ringing
    -- SIP/10.1.0.100-b44053a0 is making progress passing it to Local/901142231278@default-48b3,2
  == 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
Oct 26 10:13:01 NOTICE[9674]: rtp.c:331 process_rfc3389: Comfort noise support incomplete in Asterisk (RFC 3389). Please turn off on client if possible. Client IP: 10.1.0.100
  == Manager 'sendcron' logged off from 127.0.0.1
  == Manager 'sendcron' logged off from 127.0.0.1
  == Refreshing DNS lookups.
  == Spawn extension (default, 901142231278, 2) exited non-zero on 'Local/901142231278@default-48b3,2'
    -- Executing DeadAGI("Local/901142231278@default-48b3,2", "agi://127.0.0.1:4577/call_log") in new stack
  == Manager 'sendcron' logged off from 127.0.0.1
    -- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
    -- Executing DeadAGI("Local/901142231278@default-48b3,2", "agi://127.0.0.1:4577/VD_hangup--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------)") in new stack
    -- AGI Script agi://127.0.0.1:4577/VD_hangup--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------) completed, returning 0

But then we still wait 1-2mins before a new call gets placed.

When the Dial part runs we get an entry in the vicidial_auto_calls table with the call set to SENT, When the Hangup script is called the entry remains unchanged. I do not know much (yet) about Perl, but the VD_hangup part of FastAGI_log.pl does not seem to handle the parameter "CANCEL" anywahere that seems to be passed (my understanding of this may be wrong though).

After a little while, the entry in the table does eventually get deleted by what I presume is this section of AST_VDautodial:

Code: Select all

### delete call records that are SENT for over 2 minutes
                $stmtA = "DELETE FROM vicidial_auto_calls where server_ip='$server_ip' and call_time < '$XDSQLdate' and status NOT IN('XFER','CLOSER','LIVE')";
                $affected_rows = $dbhA->do($stmtA);

                $event_string = "|     lagged call vac agent DELETED $affected_rows|$XDSQLdate|";
                 &event_logger;

As soon as that entry goes from the table, Vicidial kicks in again and dials the next number. So from this I am guessing that the VD_hangup is not doing something that perhaps it should with the entry?

This probably would not be a massive problem with a large number of seats as aggressive predictive dialling would help, but we are running small campaigns with sometimes just one or two agents calling. This means that if say 3 calls dont get through, the agent would be sat for nearly ten minutes before getting a call and manual dialling would be faster

Just to double check I have been through the list perl modules that are listed in scratch install. We also added Getopt::Long as it is mentioned in a couple of scripts, but that has not helped.

Hopefully it is something blindingly simple and obvious that I have done wrong, but everything else seems to be ok.

Any pointers would be much appreciated as we really want this to work.

Thanks.

Chris

[rajeevpn]

are the numbers 'good'? sometimes the table gets filled with undialable numbers causing something like this !

Could you also post some logs from /var/log/astguiclient and real CLI by using screen not just asterisk -r?

thanks

[chrisbIT]

Thanks for the pointers guys. In the end I just decided on a fresh install. This time i followed the debian scratch install off the wiki and this time calls are working fine with no long pauses between calls. Am guessing it may be something to do with the perl install which in this guide uses the versions available in apt.

cheers.

Chris