vicidial.org

the uniqueid field in the vicidial tables is represented by a float 18.7 , yet in all your code it is encased in sigle quotes. That causes some weirdness. To be exact we have seen that some calls fail for inexplicable reasons , and at tracking the uniqueid is off by 0.001 .i.e. one thousandth , which is enough to mangle the stats and calls of certain agents.

The question is , can we change the uniqueid field to a char (18) or varchar(30) ? without messing vicidial totally ?

to be exact this is a log from cdr-custom/Master.csv , notice the uniqueid change for this call ( the number happens to be unique)


""M1105092516001498306" <0000000000>","0000000000","92591053004","default","Local/8600057@default-2908,1","Zap/2-1","DeadAGI","VD_hangup.agi|PRI-----NODEBUG-----16-----ANSWER-----28-----15","2007-11-05 09:25:16","2007-11-05 09:25:29","2007-11-05 09:25:44","28","15","ANSWERED","DOCUMENTATION","","1194247516.286",""

""M1105092516001498306" <0000000000>","0000000000","8600057","default","Local/8600057@default-2908,2","","DeadAGI","VD_hangup.agi|PRI-----NODEBUG-----0---------------","2007-11-05 09:25:16","2007-11-05 09:25:16","2007-11-05 09:25:44","28","28","ANSWERED","DOCUMENTATION","","1194247516.287",""

Yes you can change it to VARCHAR if you like without causing problems.

What version of MySQL are you using?

I am using
mysql Ver 14.12 Distrib 5.0.27, for redhat-linux-gnu (x86_64) using readline 5.0

Uniqueid exists in the following tables

call_log
live_inbound
live_inbound_log
park_log
vicidial_auto_calls
vicidial_log
vicidial_manager

I will change uniqueid from double(18,7) to varchar(30)

If I may ask why do you use double(18,7) while in your code you treat it as char since it is encased in sigle quotes?

The code was written with MySQL 4.0.X in mind, and a lot has changed in MySQL-land since then. I will probably do some tests to see if there would be any negative effect of switching everything to VARCHAR by default.

Unfortunately switching back to mysql 4.0.x is not a solution for me. The reason is that I use mysql's trigers in order to transparently intergrate vicidial with phpsurveyor (a survey tool http://www.limesurvey.org). It is an intersting implemetation that I can share if someone would like.
I use vicidial since June and the problem came up now after almost 1.000.000 calls. This is odd to me. Is there a way to reset uniqueid and that way things will come back to normal? Or to rephrase my question do you know how uniqueid is been generated?

We love to hear about different ways of using and integrating with VICIDIAL. Please post your story to the General forum.

As for uniqueID, it is set with the epoch(seconds since 1970-01-01 00:00:00) and a dot, then an increment of the calls on the system since last restart.

To reset uniqueID, just stop asterisk and start it up again.

Ok Matt. Thank you very much for the tip. If you perform those tests in order to upgrade in mysql 5.x please let as know.
I can sure you that float for uniqueid in mysql 5.x won't work.
Not for long any way.

Some users of BRIstuff Asterisk have already tested using VARCHAR on their systems, not sure what MySQL they were using, but because of how that fork of Asterisk does uniqueIDs(machinename-epoch.calls) you have to use VARCHAR.

The only thing I need to test is backward compatibility with MySQL 4.0.X and to see if there would be any load issues.

Hi matt, great product, btw AST_manager_listen.pl has a tiny bug at lines 354 and 366, the sql statement is not closed properly.

Could you please explain how vicidial decides to hang up certain calls ? It might help janokary and me to track the issue

What version of astguiclient are you using?

Can you post an example of the improperly closed code?

As for VICIDIAL hanging up on calls, I'm not quite sure what you mean, there is a timeout that it uses to automatically hangup non-Answered calls, are you referring to something else?

we are using
AST_manager_listen.pl version 2.0.1 *DBI-version*

and the line read
"UPDATE vicidial_manager set status='DEAD', channel='$channel' where server_ip = '$server_ip' and uniqueid = '$uniqueid' and callerid NOT LIKE \"DCagcW%";

without properly closing the like statement

The reason I am asking how vicidial hangs up the calls is because I am trying to trace a situation where calls are dropped within less than three seconds of conversation time and do not appear in vicidial_log.

I believe I can debug this since I am a seasoned perl programmer and I will post any findings back of course

Wow, that script hasn't been edited in over a year and still noone noticed the error. This will be fixed in the next SVN Commit I do. Thank you very much for pointing that out.

As for the other issue, please post what you find out with your debugging.

We are using vicidial for outgoing campaigns. We use manual dial no hotkeys. We inserted some more statuses in vicidial_status table that we often use.
We use one PRI line.

The fisrt problem we have is about droped lines

So we turned uniqueid from double to varchar(40) (we use mysql v5.0.27).
Nothing bad happend. But lines continue to drop in the same rate.

Aggelos noticed that many times asterisk thinks that a zap channel is closed but when we try to call through this channel again we get congestion message. So we have a round robin policy now and this seems to be better.
--That is what agents tell us--

But its not solved yet.

we still have drop lines

The second problem is the lost entries in vicidial_log.
(as is posted in http://www.eflo.net/VICIDIALforum/viewt ... highlight=)

At fist we thought that this has to do with the drop line issue. It has to do with it in a matter that it occurs when the lines ends (drops or whatever) at the first one or two seconds.

That is why angelos asks you how you hang up calls

Some output from the agiout.2007-XX-XX file from one of the calls that does not log would be very helpful on the dropped call issue.

here is an example

phone number 2253056707
uniqueid 1196364063.13999
caller code M1129212453001675090

the call was marked as busy and droped immediately .
Update in vicidial_log didn't take place because there was no insert at first

Ofcourse there is an update for this Busy status. But after that agent went to the dispotition screen and the call as `14` (custom status)
and this status is the one I see in vicidial_list table.

I noticed that there is not a single entry for insert into vicidial_log in agiout.
where should I find this ?

If this actions happen asynchronously this explains why there is not an entry in vicidial_log. Is that the case?



2007-11-29 21:21:03|call_log.agi|0|92253056707
2007-11-29 21:21:03|call_log.agi|AGI Environment Dump:
2007-11-29 21:21:03|call_log.agi| -- accountcode =
2007-11-29 21:21:03|call_log.agi| -- callerid = 0000000000
2007-11-29 21:21:03|call_log.agi| -- calleridname = M1129212453001675090
2007-11-29 21:21:03|call_log.agi| -- callingani2 = 0
2007-11-29 21:21:03|call_log.agi| -- callingpres = 0
2007-11-29 21:21:03|call_log.agi| -- callingtns = 0
2007-11-29 21:21:03|call_log.agi| -- callington = 0
2007-11-29 21:21:03|call_log.agi| -- channel = Local/8600055@default-74e4,1
2007-11-29 21:21:03|call_log.agi| -- context = default
2007-11-29 21:21:03|call_log.agi| -- dnid = unknown
2007-11-29 21:21:03|call_log.agi| -- enhanced = 0.0
2007-11-29 21:21:03|call_log.agi| -- extension = 92253056707
2007-11-29 21:21:03|call_log.agi| -- language = en
2007-11-29 21:21:03|call_log.agi| -- priority = 1
2007-11-29 21:21:03|call_log.agi| -- rdnis = unknown
2007-11-29 21:21:03|call_log.agi| -- request = call_log.agi
2007-11-29 21:21:03|call_log.agi| -- type = Local
2007-11-29 21:21:03|call_log.agi| -- uniqueid = 1196364063.13999
2007-11-29 21:21:03|call_log.agi|AGI Variables: |1196364063.13999|Local/8600055@default-74e4,1|92253056707|Local|M1129212453001675090|
2007-11-29 21:21:03|call_log.agi|+++++ CALL LOG START : 2007-11-29 21:21:03
2007-11-29 21:21:03|call_log.agi||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('1196364063.13999','Local/8600055@default-74e4,1','','Local','10.10.10.10','92253056707','','2007-11-29 21:21:03','1196364063','','','','','M1129212453001675090')|
2007-11-29 21:21:04|call_log.agi|AGI Environment Dump:
2007-11-29 21:21:04|call_log.agi| -- accountcode =
2007-11-29 21:21:04|call_log.agi| -- callerid = 0000000000
2007-11-29 21:21:04|call_log.agi| -- calleridname = M1129212453001675090
2007-11-29 21:21:04|call_log.agi| -- callingani2 = 0
2007-11-29 21:21:04|call_log.agi| -- callingpres = 0
2007-11-29 21:21:04|call_log.agi| -- callingtns = 0
2007-11-29 21:21:04|call_log.agi| -- callington = 0
2007-11-29 21:21:04|call_log.agi| -- channel = Local/8600055@default-74e4,1
2007-11-29 21:21:04|call_log.agi| -- context = default
2007-11-29 21:21:04|call_log.agi| -- dnid = unknown
2007-11-29 21:21:04|call_log.agi| -- enhanced = 0.0
2007-11-29 21:21:04|call_log.agi| -- extension = h
2007-11-29 21:21:04|call_log.agi| -- language = en
2007-11-29 21:21:04|call_log.agi| -- priority = 1
2007-11-29 21:21:04|call_log.agi| -- rdnis = unknown
2007-11-29 21:21:04|call_log.agi| -- request = call_log.agi
2007-11-29 21:21:04|call_log.agi| -- type = Local
2007-11-29 21:21:04|call_log.agi| -- uniqueid = 1196364063.13999
2007-11-29 21:21:04|call_log.agi|AGI Variables: |1196364063.13999|Local/8600055@default-74e4,1|h|Local|M1129212453001675090|
2007-11-29 21:21:04|call_log.agi||CALL HUNG UP|
2007-11-29 21:21:04|call_log.agi||1196364063.13999|1196364063|
2007-11-29 21:21:04|call_log.agi|QUERY done: start time = 1196364063 | sec: 1 | min: 0.02 |
2007-11-29 21:21:04|call_log.agi||UPDATE call_log set end_time='2007-11-29 21:21:04',end_epoch='1196364064',length_in_sec=1,length_in_min=' 0.02' where uniqueid='1196364063.13999'|
2007-11-29 21:21:04|call_log.agi||DELETE from live_inbound where uniqueid='1196364063.13999' and server_ip='10.10.10.10'|
2007-11-29 21:21:04|call_log.agi|+++++ CALL LOG HUNGUP: |1196364063.13999|Local/8600055@default-74e4,1|h|2007-11-29 21:21:04|min: 0.02|
2007-11-29 21:21:04|VD_hangup.agi|Perl Environment Dump:
2007-11-29 21:21:04|VD_hangup.agi|0|PRI-----NODEBUG-----17-----BUSY----------
2007-11-29 21:21:04|VD_hangup.agi|AGI Environment Dump:
2007-11-29 21:21:04|VD_hangup.agi| -- accountcode =
2007-11-29 21:21:04|VD_hangup.agi| -- callerid = 0000000000
2007-11-29 21:21:04|VD_hangup.agi| -- calleridname = M1129212453001675090
2007-11-29 21:21:04|VD_hangup.agi| -- callingani2 = 0
2007-11-29 21:21:04|VD_hangup.agi| -- callingpres = 0
2007-11-29 21:21:04|VD_hangup.agi| -- callingtns = 0
2007-11-29 21:21:04|VD_hangup.agi| -- callington = 0
2007-11-29 21:21:04|VD_hangup.agi| -- channel = Local/8600055@default-74e4,1
2007-11-29 21:21:04|VD_hangup.agi| -- context = default
2007-11-29 21:21:04|VD_hangup.agi| -- dnid = unknown
2007-11-29 21:21:04|VD_hangup.agi| -- enhanced = 0.0
2007-11-29 21:21:04|VD_hangup.agi| -- extension = h
2007-11-29 21:21:04|VD_hangup.agi| -- language = en
2007-11-29 21:21:04|VD_hangup.agi| -- priority = 2
2007-11-29 21:21:04|VD_hangup.agi| -- rdnis = unknown
2007-11-29 21:21:04|VD_hangup.agi| -- request = VD_hangup.agi
2007-11-29 21:21:04|VD_hangup.agi| -- type = Local
2007-11-29 21:21:04|VD_hangup.agi| -- uniqueid = 1196364063.13999
2007-11-29 21:21:04|VD_hangup.agi|AGI Variables: |1196364063.13999|Local/8600055@default-74e4,1|h|Local|M1129212453001675090|
2007-11-29 21:21:04|VD_hangup.agi|DEBUG: NODEBUG
2007-11-29 21:21:04|VD_hangup.agi|VD_hangup : M1129212453001675090 Local/8600055@default-74e4,1 2 1675090
2007-11-29 21:21:04|VD_hangup.agi||UPDATE vicidial_auto_calls set status='BUSY' where callerid = 'M1129212453001675090';|
2007-11-29 21:21:04|VD_hangup.agi|-- VDAC update: |0E0|1675090
2007-11-29 21:21:04|VD_hangup.agi||UPDATE vicidial_list set status='B' where lead_id = '1675090';|
2007-11-29 21:21:04|VD_hangup.agi|-- VDAD vicidial_list update: |1|1675090
2007-11-29 21:21:04|VD_hangup.agi||UPDATE vicidial_log set status='B' where uniqueid = '1196364063.13999';|
2007-11-29 21:21:04|VD_hangup.agi|-- VDAD vicidial_log update: |0E0|1196364063.13999|
2007-11-29 21:21:04|VD_hangup.agi|+++++ VDAD START LOCAL CHANNEL: EXITING- 2
2007-11-29 21:21:04|call_log.agi|AGI Environment Dump:
2007-11-29 21:21:04|call_log.agi| -- accountcode =
2007-11-29 21:21:04|call_log.agi| -- callerid = 0000000000
2007-11-29 21:21:04|call_log.agi| -- calleridname = M1129212453001675090
2007-11-29 21:21:04|call_log.agi| -- callingani2 = 0
2007-11-29 21:21:04|call_log.agi| -- callingpres = 0
2007-11-29 21:21:04|call_log.agi| -- callingtns = 0
2007-11-29 21:21:04|call_log.agi| -- callington = 0
2007-11-29 21:21:04|call_log.agi| -- channel = Local/8600055@default-74e4,2
2007-11-29 21:21:04|call_log.agi| -- context = default
2007-11-29 21:21:04|call_log.agi| -- dnid = unknown
2007-11-29 21:21:04|call_log.agi| -- enhanced = 0.0
2007-11-29 21:21:04|call_log.agi| -- extension = h
2007-11-29 21:21:04|call_log.agi| -- language = en
2007-11-29 21:21:04|call_log.agi| -- priority = 1
2007-11-29 21:21:04|call_log.agi| -- rdnis = unknown
2007-11-29 21:21:04|call_log.agi| -- request = call_log.agi
2007-11-29 21:21:04|call_log.agi| -- type = Local
2007-11-29 21:21:04|call_log.agi| -- uniqueid = 1196364063.14000
2007-11-29 21:21:04|call_log.agi|AGI Variables: |1196364063.14000|Local/8600055@default-74e4,2|h|Local|M1129212453001675090|
2007-11-29 21:21:04|call_log.agi||CALL HUNG UP|
2007-11-29 21:21:04|call_log.agi||DELETE from live_inbound where uniqueid='1196364063.14000' and server_ip='10.10.10.10'|
2007-11-29 21:21:04|call_log.agi|+++++ CALL LOG HUNGUP: |1196364063.14000|Local/8600055@default-74e4,2|h|2007-11-29 21:21:04|min: |
2007-11-29 21:21:04|VD_hangup.agi|Perl Environment Dump:
2007-11-29 21:21:04|VD_hangup.agi|0|PRI-----NODEBUG-----0---------------
2007-11-29 21:21:04|VD_hangup.agi|AGI Environment Dump:
2007-11-29 21:21:04|VD_hangup.agi| -- accountcode =
2007-11-29 21:21:04|VD_hangup.agi| -- callerid = 0000000000
2007-11-29 21:21:04|VD_hangup.agi| -- calleridname = M1129212453001675090
2007-11-29 21:21:04|VD_hangup.agi| -- callingani2 = 0
2007-11-29 21:21:04|VD_hangup.agi| -- callingpres = 0
2007-11-29 21:21:04|VD_hangup.agi| -- callingtns = 0
2007-11-29 21:21:04|VD_hangup.agi| -- callington = 0
2007-11-29 21:21:04|VD_hangup.agi| -- channel = Local/8600055@default-74e4,2
2007-11-29 21:21:04|VD_hangup.agi| -- context = default
2007-11-29 21:21:04|VD_hangup.agi| -- dnid = unknown
2007-11-29 21:21:04|VD_hangup.agi| -- enhanced = 0.0
2007-11-29 21:21:04|VD_hangup.agi| -- extension = h
2007-11-29 21:21:04|VD_hangup.agi| -- language = en
2007-11-29 21:21:04|VD_hangup.agi| -- priority = 2
2007-11-29 21:21:04|VD_hangup.agi| -- rdnis = unknown
2007-11-29 21:21:04|VD_hangup.agi| -- request = VD_hangup.agi
2007-11-29 21:21:04|VD_hangup.agi| -- type = Local
2007-11-29 21:21:04|VD_hangup.agi| -- uniqueid = 1196364063.14000
2007-11-29 21:21:04|VD_hangup.agi|AGI Variables: |1196364063.14000|Local/8600055@default-74e4,2|h|Local|M1129212453001675090|
2007-11-29 21:21:04|VD_hangup.agi|DEBUG: NODEBUG
2007-11-29 21:21:04|VD_hangup.agi|VD_hangup : M1129212453001675090 Local/8600055@default-74e4,2 2 1675090
2007-11-29 21:21:04|VD_hangup.agi|-- VDhangup Local DEBUG: |PRI| M1129212453001675090 ||0|

What version of astguiclient is this?

Is there a reason you are not using the FastAGI_log process insteade of call_log.agi and VD_hangup.agi?

We just followed the scratch install of that time !

I am jumping hte gun here but I have some preliminary debugging results.

1) Every single Update to dialstatus busy fails from VD_Hangup.agi

2007-12-03 20:59:46|VD_hangup.agi||UPDATE vicidial_log set status='B' where uniqueid = '1196708385.86399';|
2007-12-03 20:59:46|VD_hangup.agi|-- VDAD vicidial_log update: |0E0|1196708385.86399|
etc.
etc.
2) inside vdc_query_db.php the part of the code that reads if ($ACTION == 'manDiaLlogCaLL') .... is NEVER entered if the call exits with busy.

It seems to me that there is a race condition where the php code is never executed if the call exits quickly with status= BUSY/CONGESTED

All of the above under Manual Dial

Any Ideas / leads ?

We use version 2.0.1 is there a better handling of busy lines (or even better lines that drop immediately) on next versions?

And again I am trying to trace out why the insert into vicidial_log doesn’t occur on these circumstances.
I placed a log in vdc_db_query.php and I noticed that the when the line drops immediately the code after
if ($ACTION == 'manDiaLlogCaLL')
line 810 never runs

There are all sorts of bug fixes and other improvements with the 2.0.4 verions, especially compared to 2.0.1.