Alternate number dialing not working

[debtresolve]

I'm trying to get the "Auto alt-Number Dialing" feature to work but it doesn't work for me.
I've been going over the code in FastAGI_log.pl, and it seems to me that when the script is looking for a record of the call in the auto_calls table, the record does not exist (anymore?), and therefore the script skips the whole part that will put the alternate number in the hopper.
I'm posting output from FASTagiout, please let me know if I need to post any other output.

Tanks.

Code: Select all

2007-11-16 10:25:19|TEST_VDfastAGI|begin|+++++++++++++++++ FastAGI Start ++++++++++++++++++++++++++++++++++++++++
2007-11-16 10:25:19|TEST_VDfastAGI|begin|Perl Environment Dump:
2007-11-16 10:25:19|TEST_VDfastAGI|begin|0|--debug
2007-11-16 10:25:19|TEST_VDfastAGI|begin|URL HVcauses: |PRI|NODEBUG|16|||)|
2007-11-16 10:25:19|TEST_VDfastAGI|begin|AGI Environment Dump:
2007-11-16 10:25:19|TEST_VDfastAGI|begin| -- accountcode =
2007-11-16 10:25:19|TEST_VDfastAGI|begin| -- callerid = unknown
2007-11-16 10:25:19|TEST_VDfastAGI|begin| -- calleridname = S0711160824068600051
2007-11-16 10:25:19|TEST_VDfastAGI|begin| -- callingani2 = 0
2007-11-16 10:25:19|TEST_VDfastAGI|begin| -- callingpres = 0
2007-11-16 10:25:19|TEST_VDfastAGI|begin| -- callingtns = 0
2007-11-16 10:25:19|TEST_VDfastAGI|begin| -- callington = 0
2007-11-16 10:25:19|TEST_VDfastAGI|begin| -- channel = SIP/22198-0823dc00
2007-11-16 10:25:19|TEST_VDfastAGI|begin| -- context = default
2007-11-16 10:25:19|TEST_VDfastAGI|begin| -- dnid = unknown
2007-11-16 10:25:19|TEST_VDfastAGI|begin| -- enhanced = 0.0
2007-11-16 10:25:19|TEST_VDfastAGI|begin| -- extension = h
2007-11-16 10:25:19|TEST_VDfastAGI|begin| -- language = en
2007-11-16 10:25:19|TEST_VDfastAGI|begin| -- network = yes
2007-11-16 10:25:19|TEST_VDfastAGI|begin| -- network_script = VD_hangup--HVcauses--PRI-----NODEBUG-----16---------------)
2007-11-16 10:25:19|TEST_VDfastAGI|begin| -- priority = 2
2007-11-16 10:25:19|TEST_VDfastAGI|begin| -- rdnis = unknown
2007-11-16 10:25:19|TEST_VDfastAGI|begin| -- request = agi://127.0.0.1:4577/VD_hangup--HVcauses--PRI-----NODEBUG-----16---------------)
2007-11-16 10:25:19|TEST_VDfastAGI|begin| -- type = SIP
2007-11-16 10:25:19|TEST_VDfastAGI|begin| -- uniqueid = 1195230246.161
2007-11-16 10:25:19|TEST_VDfastAGI|begin|AGI Variables: |1195230246.161|SIP/22198-0823dc00|h|SIP|S0711160824068600051|
2007-11-16 10:25:19|TEST_VDfastAGI|VD_hangup|Process to run: |agi://127.0.0.1:4577/VD_hangup--HVcauses--PRI-----NODEBUG-----16---------------)|VD_hangup|END|
2007-11-16 10:25:19|TEST_VDfastAGI|VD_hangup|DEBUG: NODEBUG
2007-11-16 10:25:19|TEST_VDfastAGI|VD_hangup|VD_hangup : S0711160824068600051 SIP/22198-0823dc00 2 68600051
2007-11-16 10:25:19|TEST_VDfastAGI|VD_hangup||SELECT lead_id,callerid,campaign_id,alt_dial,stage,UNIX_TIMESTAMP(call_time) FROM vicidial_auto_calls where uniqueid = '119
5230246.161' limit 1;|
2007-11-16 10:25:19|TEST_VDfastAGI|VD_hangup|VD hangup: no VDAC record found: 1195230246.161 S0711160824068600051


[mflorell]

Auto-Alt-Dial is triggered several places, the FastAGIlog trigger is only for DC(Disconnect), NA or Busy calls, all other Auto-Alt-Dial statuses are triggered from either the auto-dial script or the agent application.

What status was this lead when it was hing up?

[debtresolve]

The status in the vicidial_list table stayed NEW, I'm not sure why. It should have been either a AM (answering machine) or Busy
in this campaign I was using 2 numbers 1 was a real number that went to AM, the other was setup in Asterisk to give a busy signal:
exten => 13213214321,1,Busy
exten => 13213214321,2,Hangup

Actually, it seems to me that the status in the vicidial_list table is the problem, I just ran the folowing query:

Code: Select all

mysql> select status, count(*) from vicidial_list where user = 'VDAD' and called_since_last_reset='Y' group by status;
+--------+----------+
| status | count(*) |
+--------+----------+
| A      |     1391 |
| CALLBK |        1 |
| DROP   |    10140 |
| NA     |       48 |
| NEW    |    49254 |
+--------+----------+
5 rows in set (0.65 sec)


this does not seem right to me, I believe that something is not dipositioning these calls right, I should have seen also Busy, DC and AM statuses in here and also I expected more then 48 NA.

I believe we're on to something here, but I don't know where to look now.......

[artimus]

We noticed that vici often leaves the status as "NEW" after dialing a lead. What could cause this to happen? I don't see that it is possible for a dialed lead to still have a status of "NEW". What could cause this behavior?

[mflorell]

You are missing a call_log AGI entry in your dialout string somewhere in extensions.conf.

[artimus]

Ha, I think your right.

Looking at it, I can see a while back we were messing around with how we pass outbound calls to the iax trunk. The final result did not run call_log. I'm putting that in now to see if it makes a difference, which I assume it will.


Also I noticed that the inbound groups do not use call_log. I copied it from the section of the sample config which also did not use call_log (this is the inbound t1 pri section). Is there a reason why call_log is not called here, or should I add it in? As far as I know, I don't think there is any trouble with inbound calls.

[artimus]

I spoke to soon.
At first it looked like our problem was going away, but after I checked last, I can see that we are still getting "NEW" calls that have already been dialed.

mysql> select status, count(*) from vicidial_list where modify_date > current_timestamp - interval 5 minute AND called_since_last_reset != 'N' group by status;

Code: Select all

Originally
+--------+----------+
| status | count(*) |
+--------+----------+
| A      |        7 |
| B      |       16 |
| INCALL |        3 |
| NA     |       59 |
| NEW    |       62 |
| SKP    |        1 |
| SPC    |        1 |
+--------+----------+

A few minutes after the change
+--------+----------+
| status | count(*) |
+--------+----------+
| A      |        7 |
| B      |       12 |
| INCALL |        1 |
| LM1    |        3 |
| NA     |      127 |
| NEW    |       28 |
| SPC    |        1 |
| TRN    |        1 |
| WNP    |        2 |
| WRG    |        2 |
+--------+----------+

A few minutes after that
+--------+----------+
| status | count(*) |
+--------+----------+
| A      |        9 |
| B      |       10 |
| INCALL |        2 |
| LM1    |        2 |
| NA     |      137 |
| NA1    |        2 |
| NEW    |       30 |
| SPC    |        1 |
| TRN    |        1 |
| WNP    |        1 |
| WRG    |        2 |
+--------+----------+


Looks like the new status is still incrementing.

[mflorell]

Can you confirm that those NEW leads are actually being dialed?

I have seen companies not filtering their leads (i.e. 72712345678) which cannot be dialed in the US since the prefix begins with a 1 so it does not go through the dialplan and does not get logged and will stay as a NEW lead.