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",""
unique id
Moderators: gerski, enjay, williamconley, Op3r, Staydog, gardo, mflorell, MJCoate, mcargile, Kumba, Michael_N
20 posts
• Page 1 of 1
by janokary » Tue Nov 06, 2007 2:40 am
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?
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?
- janokary
- Posts: 21
- Joined: Thu May 31, 2007 2:08 am
- Location: Greece
by mflorell » Tue Nov 06, 2007 7:52 am
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.
- mflorell
- Site Admin
- Posts: 18387
- Joined: Wed Jun 07, 2006 2:45 pm
- Location: Florida
by janokary » Tue Nov 06, 2007 1:58 pm
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?
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?
- janokary
- Posts: 21
- Joined: Thu May 31, 2007 2:08 am
- Location: Greece
by mflorell » Tue Nov 06, 2007 3:13 pm
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.
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.
- mflorell
- Site Admin
- Posts: 18387
- Joined: Wed Jun 07, 2006 2:45 pm
- Location: Florida
by janokary » Tue Nov 06, 2007 4:01 pm
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.
I can sure you that float for uniqueid in mysql 5.x won't work.
Not for long any way.
- janokary
- Posts: 21
- Joined: Thu May 31, 2007 2:08 am
- Location: Greece
by mflorell » Tue Nov 06, 2007 4:49 pm
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.
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.
- mflorell
- Site Admin
- Posts: 18387
- Joined: Wed Jun 07, 2006 2:45 pm
- Location: Florida
hangup command
by angelos » Wed Nov 28, 2007 11:42 am
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
Could you please explain how vicidial decides to hang up certain calls ? It might help janokary and me to track the issue
- angelos
- Posts: 7
- Joined: Wed Nov 28, 2007 11:15 am
- Location: Greece
by mflorell » Wed Nov 28, 2007 8:07 pm
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?
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?
- mflorell
- Site Admin
- Posts: 18387
- Joined: Wed Jun 07, 2006 2:45 pm
- Location: Florida
bug
by angelos » Thu Nov 29, 2007 10:30 am
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
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
- angelos
- Posts: 7
- Joined: Wed Nov 28, 2007 11:15 am
- Location: Greece
by mflorell » Thu Nov 29, 2007 8:07 pm
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.
As for the other issue, please post what you find out with your debugging.
- mflorell
- Site Admin
- Posts: 18387
- Joined: Wed Jun 07, 2006 2:45 pm
- Location: Florida
by janokary » Fri Nov 30, 2007 11:02 am
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
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
- janokary
- Posts: 21
- Joined: Thu May 31, 2007 2:08 am
- Location: Greece
agiout
by janokary » Mon Dec 03, 2007 5:17 am
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|
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|
- janokary
- Posts: 21
- Joined: Thu May 31, 2007 2:08 am
- Location: Greece
jumping the gun
by angelos » Tue Dec 04, 2007 4:45 am
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 ?
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 ?
- angelos
- Posts: 7
- Joined: Wed Nov 28, 2007 11:15 am
- Location: Greece
by janokary » Tue Dec 04, 2007 4:49 am
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
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
- janokary
- Posts: 21
- Joined: Thu May 31, 2007 2:08 am
- Location: Greece
20 posts
• Page 1 of 1
Who is online
Users browsing this forum: Google [Bot], mawais and 130 guests