vicidial.org

I am working to resolve an issue with call routing it is happening on 3 separate deployments.

Asterisk - 11.22
Vici - 2.12-552a

Initially issue presented itself as calls that are shown as waiting in Q but had no number for the lead or campaign, when looking at realtime report. These calls were tagged as 0 priority and set as OUT not OUTBLANACE. All calls on these servers should be OUTBLANCE calls.
After looking in to this i found that these records appeared in vicidial_auto_calls table but had no phone number, or phone_code(blank) and lead ID was set as last 5 digits of the number and "callerid"(this filed holds session number that starts with V foru outbound) field has leads phone number and 4 digits attached at the front.

here is an example of this record
In this phone number that was being called is 2229433537
lead_id value = 33537
callerid value = 409912229433537 - (this value is wrong)

4458662 10.1.1.100 LIVE 33537 1490203455.89683 409912229433537 SIP/carrier-00006cbc 2017-03-22 13:24:32 OUT LIVE-2.75 2017-03-22 13:24:35 NONE 0
code that does this insert seems to trace to - usr/share/astguiclient/AST_VDauto_dial.pl

Moving further I found that call_log also has wrong data for these calls, there are two entries for each outbound call, one local and on for the carrier. Local part has correct callerid value but carrier entry always contains wrong value, same as vicidial_auto_calls

AMD logs also reflect issues showing correct lead_id(shows something like 57 instead of 6 digit lead id) and and phone number .

What seems to happen is agi scripting incorrectly pulls data apart when processing the call and ends up providing wrong information, I am working on pilling agi login apart but maybe this is something that has already been solved. Or someone knows where logic that may cause this resides?

If you need more information I have plenty of log examples from log tables to binary mysql logs tracking these calls.

Thanks

I found some strange callerid values that include varables, from call processing.

For example here is insert entry for one of these calls from mysql binary log, notice that caller_code value is not what it is expected to look like, 12222226868rn=2672219469npdi=yes, while it should look something like V3231336010019077372

INSERT INTO call_log (uniqueid,channel,channel_group,type,server_ip,extension,number_dialed,start_time,start_epoch,end_time,end_epoch,length_in_sec,length_in_min,caller_code)
values('1490202656.81498','Local/312222226868@default-000062df;1','Local Channel Line','Local','10.1.1.100','8369','8369','2017-03-22 13:11:26','1490202686','','','','','12222226868rn=3333339469npdi=yes')

caller_code value is too long to it gets cut off and appears as 12222226868rn=333333 in the database

My suspicion is that for some reason system is trying to process these calls as inbound while they are actually outbound calls and this seems to happen when call is routed to AMD extension 8369