We are using VICIDIAL 2.0.3 with Asterisk 1.2.14 at a call center with about 7 agents.
Everything works fine for the first few hours, but then eventually the predictive dialer stops to dial new leads. The hopper is fully loaded and there are still plenty of leads available to dial. Using adaptive dialing, the dial_level has raised to the maximum allowable level, but the reports screen display "NO LIVE CALLS WAITING". Also the Asterisk CLI does not show that there are any calls being made. All agent's statuses is on READY.
At the time of this happing, this is the content of the vicidial_auto_calls table:
38496,"192.168.2.20","ORPHAN","XFER",38122,1178613680.1056001,"M0508104120000038122","","","0732515228","2007-05-08 10:41:20","OUT","START","2007-05-08 10:41:27","NONE"
38561,"192.168.2.20","ORPHAN","XFER",37025,1178615218.1359000,"M0508110658000037025","","27","0828314110","2007-05-08 11:06:58","OUT","START","2007-05-08 11:07:08","NONE"
38523,"192.168.2.20","ORPHAN","XFER",38028,1178614258.1187000,"M0508105058000038028","","27","0845648064","2007-05-08 10:50:58","OUT","START","2007-05-08 10:51:07","NONE"
38547,"192.168.2.20","ORPHAN","XFER",37063,1178620327.2307000,"M0508110044000037063","","27","0828579743","2007-05-08 11:00:44","OUT","START","2007-05-08 12:32:18","NONE"
38563,"192.168.2.20","ORPHAN","XFER",36101,1178615341.1373999,"M0508110901000036101","","27","0729074868","2007-05-08 11:09:01","OUT","START","2007-05-08 11:09:07","NONE"
38543,"192.168.2.20","ORPHAN","XFER",37387,1178614639.1273999,"M0508105719000037387","","27","0833270317","2007-05-08 10:57:19","OUT","START","2007-05-08 10:57:43","NONE"
38539,"192.168.2.20","ORPHAN","XFER",37268,1178614544.1256001,"M0508105543000037268","","27","0832609183","2007-05-08 10:55:43","OUT","START","2007-05-08 10:55:51","NONE"
38532,"192.168.2.20","ORPHAN","XFER",35925,1178614426.1224999,"M0508105346000035925","","27","0724632211","2007-05-08 10:53:46","OUT","START","2007-05-08 10:53:56","NONE"
38564,"192.168.2.20","ORPHAN","XFER",36603,1178622651.2413001,"M0508111027000036603","","27","0824128572","2007-05-08 11:10:27","OUT","START","2007-05-08 13:10:58","NONE"
38562,"192.168.2.20","ORPHAN","XFER",37714,1178617376.1810999,"M0508110705000037714","","27","0835921433","2007-05-08 11:07:05","OUT","START","2007-05-08 11:43:03","NONE"
38565,"192.168.2.20","ORPHAN","XFER",36603,1178622651.2413001,"M0508111101000036603","","27","0824128572","2007-05-08 11:11:01","OUT","START","2007-05-08 13:10:58","NONE"
38725,"192.168.2.20","ORPHAN","XFER",37978,1178619521.2212000,"M0508121841000037978","","27","0842907597","2007-05-08 12:18:41","OUT","START","2007-05-08 12:18:47","NONE"
38679,"192.168.2.20","ORPHAN","XFER",37525,1178618110.1973000,"M0508115351000037525","","27","0834354926","2007-05-08 11:53:51","OUT","START","2007-05-08 11:55:16","NONE"
38582,"192.168.2.20","ORPHAN","XFER",12347,1178615787.1468999,"M0508111627000012347","","27","0478740112","2007-05-08 11:16:27","OUT","START","2007-05-08 11:16:29","NONE"
38652,"192.168.2.20","ORPHAN","XFER",37714,1178617376.1810999,"M0508114256000037714","","27","0835921433","2007-05-08 11:42:56","OUT","START","2007-05-08 11:43:03","NONE"
38575,"192.168.2.20","ORPHAN","XFER",38123,1178615736.1440001,"M0508111535000038123","","000","0733910222","2007-05-08 11:15:35","OUT","START","2007-05-08 11:15:38","NONE"
38682,"192.168.2.20","ORPHAN","XFER",37525,1178618110.1973000,"M0508115510000037525","","27","0834354926","2007-05-08 11:55:10","OUT","START","2007-05-08 11:55:16","NONE"
38574,"192.168.2.20","ORPHAN","XFER",12310,1178615727.1435001,"M0508111527000012310","","27","0834773136","2007-05-08 11:15:27","OUT","START","2007-05-08 11:15:32","NONE"
38676,"192.168.2.20","ORPHAN","XFER",12404,1178620185.2297001,"M0508115322000012404","","27","0822207511","2007-05-08 11:53:22","OUT","START","2007-05-08 12:29:48","NONE"
38681,"192.168.2.20","ORPHAN","XFER",37525,1178618110.1973000,"M0508115434000037525","","27","0834354926","2007-05-08 11:54:34","OUT","START","2007-05-08 11:55:16","NONE"
38641,"192.168.2.20","ORPHAN","XFER",37883,1178617125.1756001,"M0508113844000037883","","27","0837625628","2007-05-08 11:38:44","OUT","START","2007-05-08 11:38:49","NONE"
38715,"192.168.2.20","ORPHAN","XFER",37035,1178619339.2196000,"M0508121051000037035","","27","0828453566","2007-05-08 12:10:51","OUT","START","2007-05-08 12:15:49","NONE"
38666,"192.168.2.20","ORPHAN","XFER",38010,1178617806.1886001,"M0508115006000038010","","27","0844220141","2007-05-08 11:50:06","OUT","START","2007-05-08 11:50:13","NONE"
38711,"192.168.2.20","ORPHAN","XFER",1058,1178618965.2135999,"M0508120925000001058","","27","0737262788","2007-05-08 12:09:25","OUT","START","2007-05-08 12:09:30","NONE"
38700,"192.168.2.20","ORPHAN","XFER",12630,1178618717.2084999,"M0508120517000012630","","27","0216572249","2007-05-08 12:05:17","OUT","START","2007-05-08 12:05:20","NONE"
38712,"192.168.2.20","ORPHAN","XFER",36248,1178629315.2811000,"M0508120947000036248","","27","0733137331","2007-05-08 12:09:47","OUT","START","2007-05-08 15:01:58","NONE"
38718,"192.168.2.20","ORPHAN","XFER",37035,1178619339.2196000,"M0508121409000037035","","27","0828453566","2007-05-08 12:14:09","OUT","START","2007-05-08 12:15:49","NONE"
38733,"192.168.2.20","ORPHAN","XFER",37538,1178620114.2275000,"M0508122833000037538","","27","0834442076","2007-05-08 12:28:33","OUT","START","2007-05-08 12:28:38","NONE"
38728,"192.168.2.20","ORPHAN","XFER",37692,1178619792.2246001,"M0508122312000037692","","27","0835801235","2007-05-08 12:23:12","OUT","START","2007-05-08 12:23:19","NONE"
38732,"192.168.2.20","ORPHAN","XFER",37661,1178620003.2270000,"M0508122642000037661","","27","0835525869","2007-05-08 12:26:42","OUT","START","2007-05-08 12:26:47","NONE"
38722,"192.168.2.20","ORPHAN","XFER",37035,1178619339.2196000,"M0508121539000037035","","27","0828453566","2007-05-08 12:15:39","OUT","START","2007-05-08 12:15:49","NONE"
38734,"192.168.2.20","ORPHAN","XFER",12404,1178620185.2297001,"M0508122907000012404","","27","0822207511","2007-05-08 12:29:07","OUT","START","2007-05-08 12:29:48","NONE"
38735,"192.168.2.20","ORPHAN","XFER",12404,1178620185.2297001,"M0508122912000012404","","27","9311170","2007-05-08 12:29:12","OUT","START","2007-05-08 12:29:48","NONE"
38736,"192.168.2.20","ORPHAN","XFER",12404,1178620185.2297001,"M0508122945000012404","","27","0459311170","2007-05-08 12:29:45","OUT","START","2007-05-08 12:29:48","NONE"
38737,"192.168.2.20","ORPHAN","XFER",7067,1178620239.2302001,"M0508123039000007067","","27","0835395434","2007-05-08 12:30:39","OUT","START","2007-05-08 12:30:46","NONE"
38738,"192.168.2.20","ORPHAN","XFER",37063,1178620327.2307000,"M0508123207000037063","","27","0828579743","2007-05-08 12:32:07","OUT","START","2007-05-08 12:32:18","NONE"
38739,"192.168.2.20","ORPHAN","XFER",37734,1178622755.2440000,"M0508125330000037734","","27","0836183300","2007-05-08 12:53:30","OUT","START","2007-05-08 13:12:37","NONE"
38740,"192.168.2.20","ORPHAN","XFER",37734,1178622755.2440000,"M0508125356000037734","","27","0836183300","2007-05-08 12:53:56","OUT","START","2007-05-08 13:12:37","NONE"
38741,"192.168.2.20","ORPHAN","XFER",37507,1178621772.2349999,"M0508125542000037507","","27","0834226393","2007-05-08 12:55:42","OUT","START","2007-05-08 12:56:20","NONE"
38742,"192.168.2.20","ORPHAN","XFER",37507,1178621772.2349999,"M0508125612000037507","","27","0834226393","2007-05-08 12:56:12","OUT","START","2007-05-08 12:56:20","NONE"
38743,"192.168.2.20","ORPHAN","XFER",12644,1178621961.2356999,"M0508125921000012644","","27","0820610197","2007-05-08 12:59:21","OUT","START","2007-05-08 12:59:28","NONE"
38744,"192.168.2.20","ORPHAN","XFER",12315,1178622082.2362001,"M0508130122000012315","","27","0414643260","2007-05-08 13:01:22","OUT","START","2007-05-08 13:01:24","NONE"
38745,"192.168.2.20","ORPHAN","XFER",37734,1178622755.2440000,"M0508130324000037734","","27","0836183300","2007-05-08 13:03:24","OUT","START","2007-05-08 13:12:37","NONE"
38746,"192.168.2.20","ORPHAN","XFER",37734,1178622755.2440000,"M0508130354000037734","","27","0116555684","2007-05-08 13:03:54","OUT","START","2007-05-08 13:12:37","NONE"
38747,"192.168.2.20","ORPHAN","XFER",38046,,"M0508130656000038046","","27","0846260261","2007-05-08 13:06:56","OUT","START","2007-05-08 13:06:56","NONE"
38748,"192.168.2.20","ORPHAN","XFER",37830,1178622723.2420001,"M0508131012000037830","","27","0837252343","2007-05-08 13:10:12","OUT","START","2007-05-08 13:12:04","NONE"
38749,"192.168.2.20","ORPHAN","XFER",37830,1178622723.2420001,"M0508131012000037830","","27","0837252343","2007-05-08 13:10:12","OUT","START","2007-05-08 13:12:04","NONE"
38750,"192.168.2.20","ORPHAN","XFER",38075,,"M0508131016000038075","","27","0847465841","2007-05-08 13:10:16","OUT","START","2007-05-08 13:10:16","NONE"
38751,"192.168.2.20","ORPHAN","XFER",36603,1178622651.2413001,"M0508131018000036603","","27","0824128572","2007-05-08 13:10:18","OUT","START","2007-05-08 13:10:58","NONE"
38752,"192.168.2.20","ORPHAN","XFER",36603,1178622651.2413001,"M0508131051000036603","","27","0824128572","2007-05-08 13:10:51","OUT","START","2007-05-08 13:10:58","NONE"
38753,"192.168.2.20","ORPHAN","XFER",37830,1178622723.2420001,"M0508131203000037830","","27","0837252343","2007-05-08 13:12:03","OUT","START","2007-05-08 13:12:04","NONE"
38754,"192.168.2.20","ORPHAN","XFER",36144,1178628079.2739000,"M0508131216000036144","","27","0731614416","2007-05-08 13:12:16","OUT","START","2007-05-08 14:41:25","NONE"
38755,"192.168.2.20","ORPHAN","XFER",38124,1178622745.2430000,"M0508131225000038124","","2","0113244405","2007-05-08 13:12:25","OUT","START","2007-05-08 13:12:27","NONE"
38756,"192.168.2.20","ORPHAN","XFER",37840,1178622748.2435000,"M0508131228000037840","","27","0837312040","2007-05-08 13:12:28","OUT","START","2007-05-08 13:12:30","NONE"
38757,"192.168.2.20","ORPHAN","XFER",37734,1178622755.2440000,"M0508131235000037734","","27","0836183300","2007-05-08 13:12:35","OUT","START","2007-05-08 13:12:37","NONE"
38758,"192.168.2.20","ORPHAN","XFER",36144,1178628079.2739000,"M0508131250000036144","","27","0731614416","2007-05-08 13:12:50","OUT","START","2007-05-08 14:41:25","NONE"
38759,"192.168.2.20","ORPHAN","XFER",37683,1178622976.2467000,"M0508131522000037683","","27","0835722274","2007-05-08 13:15:22","OUT","START","2007-05-08 13:16:21","NONE"
38760,"192.168.2.20","ORPHAN","XFER",37683,1178622976.2467000,"M0508131615000037683","","27","0835722274","2007-05-08 13:16:15","OUT","START","2007-05-08 13:16:21","NONE"
38761,"192.168.2.20","ORPHAN","XFER",37817,1178626289.2620001,"M0508131741000037817","","27","0837041551","2007-05-08 13:17:41","OUT","START","2007-05-08 14:11:36","NONE"
38762,"192.168.2.20","ORPHAN","XFER",37817,1178626289.2620001,"M0508131826000037817","","27","0837041551","2007-05-08 13:18:26","OUT","START","2007-05-08 14:11:36","NONE"
38763,"192.168.2.20","ORPHAN","XFER",38045,1178629148.2801001,"M0508132034000038045","","27","0846114439","2007-05-08 13:20:34","OUT","START","2007-05-08 14:59:15","NONE"
38764,"192.168.2.20","ORPHAN","XFER",37745,1178623411.2516999,"M0508132331000037745","","27","0836292845","2007-05-08 13:23:31","OUT","START","2007-05-08 13:23:38","NONE"
38765,"192.168.2.20","ORPHAN","XFER",36663,,"M0508132543000036663","","27","0824438256","2007-05-08 13:25:43","OUT","START","2007-05-08 13:25:43","NONE"
38766,"192.168.2.20","ORPHAN","XFER",36663,,"M0508132549000036663","","27","0824438256","2007-05-08 13:25:49","OUT","START","2007-05-08 13:25:49","NONE"
38767,"192.168.2.20","ORPHAN","XFER",37817,1178626289.2620001,"M0508141129000037817","","27","0837041551","2007-05-08 14:11:29","OUT","START","2007-05-08 14:11:36","NONE"
38768,"192.168.2.20","ORPHAN","XFER",36248,1178629315.2811000,"M0508142503000036248","","27","0733137331","2007-05-08 14:25:03","OUT","START","2007-05-08 15:01:58","NONE"
38769,"192.168.2.20","ORPHAN","XFER",37415,1178627192.2665000,"M0508142632000037415","","27","0833515730","2007-05-08 14:26:32","OUT","START","2007-05-08 14:26:39","NONE"
38770,"192.168.2.20","ORPHAN","XFER",12241,1178627297.2690001,"M0508142756000012241","","27","0828402263","2007-05-08 14:27:56","OUT","START","2007-05-08 14:28:20","NONE"
38771,"192.168.2.20","ORPHAN","XFER",12241,1178627297.2690001,"M0508142817000012241","","27","0828402263","2007-05-08 14:28:17","OUT","START","2007-05-08 14:28:20","NONE"
38772,"192.168.2.20","ORPHAN","XFER",36428,1178627950.2725999,"M0508143910000036428","","27","0822092355","2007-05-08 14:39:10","OUT","START","2007-05-08 14:39:18","NONE"
38773,"192.168.2.20","ORPHAN","XFER",36144,1178628079.2739000,"M0508144041000036144","","27","0731614416","2007-05-08 14:40:41","OUT","START","2007-05-08 14:41:25","NONE"
38774,"192.168.2.20","ORPHAN","XFER",36144,1178628079.2739000,"M0508144119000036144","","27","0731614416","2007-05-08 14:41:19","OUT","START","2007-05-08 14:41:25","NONE"
38775,"192.168.2.20","ORPHAN","XFER",38125,1178628801.2767000,"M0508145320000038125","","102","0114111888","2007-05-08 14:53:20","OUT","START","2007-05-08 14:53:23","NONE"
38776,"192.168.2.20","ORPHAN","XFER",38125,,"M0508145457000038125","","102","0114111888","2007-05-08 14:54:57","OUT","START","2007-05-08 14:54:57","NONE"
38777,"192.168.2.20","ORPHAN","XFER",38051,1178628943.2786000,"M0508145523000038051","","27","0846553225","2007-05-08 14:55:23","OUT","START","2007-05-08 14:55:49","NONE"
38778,"192.168.2.20","ORPHAN","XFER",38051,1178628943.2786000,"M0508145543000038051","","27","0846553225","2007-05-08 14:55:43","OUT","START","2007-05-08 14:55:49","NONE"
38779,"192.168.2.20","ORPHAN","XFER",37988,1178629018.2795000,"M0508145658000037988","","27","0843188264","2007-05-08 14:56:58","OUT","START","2007-05-08 14:57:05","NONE"
38780,"192.168.2.20","ORPHAN","XFER",38045,1178629148.2801001,"M0508145907000038045","","27","0846114439","2007-05-08 14:59:07","OUT","START","2007-05-08 14:59:15","NONE"
38781,"192.168.2.20","ORPHAN","XFER",36248,1178629315.2811000,"M0508150155000036248","","27","0733137331","2007-05-08 15:01:55","OUT","START","2007-05-08 15:01:58","NONE"
38782,"192.168.2.20","ORPHAN","XFER",38126,1178629482.2818000,"M0508150441000038126","","11","0732516912","2007-05-08 15:04:41","OUT","START","2007-05-08 15:04:47","NONE"
38783,"192.168.2.20","ORPHAN","XFER",38127,1178629842.2859001,"M0508150523000038127","","102","0728748000","2007-05-08 15:05:23","OUT","START","2007-05-08 15:10:52","NONE"
38784,"192.168.2.20","ORPHAN","XFER",38127,1178629842.2859001,"M0508150557000038127","","102","0728748000","2007-05-08 15:05:57","OUT","START","2007-05-08 15:10:52","NONE"
38785,"192.168.2.20","ORPHAN","XFER",38127,1178629842.2859001,"M0508150634000038127","","102","0728748000","2007-05-08 15:06:34","OUT","START","2007-05-08 15:10:52","NONE"
38786,"192.168.2.20","ORPHAN","XFER",38127,1178629842.2859001,"M0508151042000038127","","102","0728748000","2007-05-08 15:10:42","OUT","START","2007-05-08 15:10:52","NONE"
38787,"192.168.2.20","ORPHAN","XFER",35760,1178629978.2866001,"M0508151258000035760","","27","0826406403","2007-05-08 15:12:58","OUT","START","2007-05-08 15:13:07","NONE"
38788,"192.168.2.20","ORPHAN","XFER",37361,1178630228.2876999,"M0508151707000037361","","27","0833073551","2007-05-08 15:17:07","OUT","START","2007-05-08 15:17:14","NONE"
38789,"192.168.2.20","ORPHAN","XFER",38125,,"M0508151852000038125","","102","0114111888","2007-05-08 15:18:52","OUT","START","2007-05-08 15:18:52","NONE"
As soon as I do a "DELETE FROM vicidial_auto_calls" the predictive dialing starts to work again like usual. Why does this happen and I can prevent it?
Predictive dialer gets stuck
Moderators: gerski, enjay, williamconley, Op3r, Staydog, gardo, mflorell, MJCoate, mcargile, Kumba, Michael_N
26 posts
• Page 1 of 1
Predictive dialer gets stuck
by caspar » Tue May 08, 2007 8:29 am
- caspar
- Posts: 111
- Joined: Thu Dec 21, 2006 6:55 am
- Location: South Africa
by chander.prakash » Wed May 09, 2007 3:37 pm
Dear Caspar,
Use the following patch. I had put it up some time back. The problem that you are facing should get resolved.
It will work with any version as it is handling only the DB.
http://www.eflo.net/VICIDIALmantis/view.php?id=92
# Put this file in folder named /usr/share/astguiclient
# You need to put this as a CRONTAB entry
* * * * * /usr/share/astguiclient/AST_CLEAR_VICIDIAL_BLOCK.pl
#
# !!! RUN THIS WHILE THERE ARE ACTIVE CALLS ON THE ASTERISK SERVER !!!
_________________
Thanks
Chander
Email: vicidial.professional@gmail.com
Use the following patch. I had put it up some time back. The problem that you are facing should get resolved.
It will work with any version as it is handling only the DB.
http://www.eflo.net/VICIDIALmantis/view.php?id=92
# Put this file in folder named /usr/share/astguiclient
# You need to put this as a CRONTAB entry
* * * * * /usr/share/astguiclient/AST_CLEAR_VICIDIAL_BLOCK.pl
#
# !!! RUN THIS WHILE THERE ARE ACTIVE CALLS ON THE ASTERISK SERVER !!!
_________________
Thanks
Chander
Email: vicidial.professional@gmail.com
- chander.prakash
- Posts: 46
- Joined: Sat Feb 17, 2007 6:52 pm
by tbenson » Wed May 09, 2007 8:51 pm
The only time I see this many inside the vicidial_auto_calls is when one of the dialplan's in extensions.conf is missing the AGI(call_log.agi). This will orphan entries in the vicidial_auto_calls table as they are not being handled properly.
But with adaptive and 7 agents, and a max adapt of 3 you should stop around 18-21 entries (also based on if Tally is set to Y or N). If you grow wildly beyond your AGENTS X MAX_ADAPT (the 50-70 i see here) then i suggest grooming your extensions.conf closely, as it continues to grow and grow if you have dialplans you are using that initiate calls from the Call Center.
The way I saw it grow beyond expectations was when they stopped calling and sat in resume for 3-5 minutes, they would start doing callbacks, and manual dials. Initiating the call even when the system scipt would have Calls to make: -1. If this dialplan you just matched with has no AGI(call_log.agi) then you now gain a new vicidial_auto_calls entry that will be orphaned when the line is hungup by your agent. Thus 7 agents with a max adapt of 3 and 21 orphaned auto_calls can increase the auto_calls up to 60-100 over the course of 10-20 minutes of callbacks and manual dialing. Thus your now at Calls to make: -50 or more, and fighting a loosing battle to regain autodialing.
We have not implemented the script mentioned previously although I am not sure if it just flushes vicidial_auto_calls or does logic to track actual active channels in the system and flush only the non active ones.
All in all this may not help you at all, but if your auto_calls are increasing beyond your agents multiplied by your max adapt level, then i suggest looking into your dialplan very carefully, as I dont see any other reason (short of the unique_id or caller_id field not matching when hungup (whichever is used to remove the call from the vicidial_auto_calls table), which I do not remember how that part works.
Trevor
But with adaptive and 7 agents, and a max adapt of 3 you should stop around 18-21 entries (also based on if Tally is set to Y or N). If you grow wildly beyond your AGENTS X MAX_ADAPT (the 50-70 i see here) then i suggest grooming your extensions.conf closely, as it continues to grow and grow if you have dialplans you are using that initiate calls from the Call Center.
The way I saw it grow beyond expectations was when they stopped calling and sat in resume for 3-5 minutes, they would start doing callbacks, and manual dials. Initiating the call even when the system scipt would have Calls to make: -1. If this dialplan you just matched with has no AGI(call_log.agi) then you now gain a new vicidial_auto_calls entry that will be orphaned when the line is hungup by your agent. Thus 7 agents with a max adapt of 3 and 21 orphaned auto_calls can increase the auto_calls up to 60-100 over the course of 10-20 minutes of callbacks and manual dialing. Thus your now at Calls to make: -50 or more, and fighting a loosing battle to regain autodialing.
We have not implemented the script mentioned previously although I am not sure if it just flushes vicidial_auto_calls or does logic to track actual active channels in the system and flush only the non active ones.
All in all this may not help you at all, but if your auto_calls are increasing beyond your agents multiplied by your max adapt level, then i suggest looking into your dialplan very carefully, as I dont see any other reason (short of the unique_id or caller_id field not matching when hungup (whichever is used to remove the call from the vicidial_auto_calls table), which I do not remember how that part works.
Trevor
- tbenson
- Posts: 116
- Joined: Wed Mar 07, 2007 8:41 pm
- Location: California
by caspar » Thu May 10, 2007 5:45 am
Thanks a lot Chander! I have downloaded your patch and will apply it if all else fails. In the mean time I am trying to understand why this is happening.
Trevor, thanks a lot for your advice. I did customize the dial plan for the client and will look at it again.
I am calling AGI(agi://127.0.0.1:4577/call_log) on the following:
- all outbound calls (though from a macro, do not know if this is an issue)
- on the h extension
- on the transfer extensions: 8364, 8365, 8366, 8372
Did I miss something? Should I use AGI(call_log.agi) instead?
My hang up extension looks like this:
exten => h,1,DeadAGI(agi://127.0.0.1:4577/call_log)
exten => h,2,DeadAGI(agi://127.0.0.1:4577/VD_hangup--HVcause ... ---NODEBUG
-----${HANGUPCAUSE}-----${DIALSTATUS}-----${DIALEDTIME}-----${ANSWEREDTIME}))
Trevor, thanks a lot for your advice. I did customize the dial plan for the client and will look at it again.
This is indeed the case.The way I saw it grow beyond expectations was when they stopped calling and sat in resume for 3-5 minutes, they would start doing callbacks, and manual dials.
I am calling AGI(agi://127.0.0.1:4577/call_log) on the following:
- all outbound calls (though from a macro, do not know if this is an issue)
- on the h extension
- on the transfer extensions: 8364, 8365, 8366, 8372
Did I miss something? Should I use AGI(call_log.agi) instead?
My hang up extension looks like this:
exten => h,1,DeadAGI(agi://127.0.0.1:4577/call_log)
exten => h,2,DeadAGI(agi://127.0.0.1:4577/VD_hangup--HVcause ... ---NODEBUG
-----${HANGUPCAUSE}-----${DIALSTATUS}-----${DIALEDTIME}-----${ANSWEREDTIME}))
- caspar
- Posts: 111
- Joined: Thu Dec 21, 2006 6:55 am
- Location: South Africa
by tbenson » Thu May 10, 2007 9:18 am
caspar wrote:Did I miss something? Should I use AGI(call_log.agi) instead?
Not sure, every line we have is the first step is AGI(call_log.agi) I would have to setup one doing the call via AGI(agi://127.0.0.1:4577/call_log) to test. I assume if you feed the AGI the protocol and IP you can drop the .agi from the end of the filename? If not then you may just be missing the last .agi in the line, however we just call the file via AGI(filename.agi) because it is a local call.
Sort of sounds like the AGI call you are making is not getting to call_log.agi and orphaning the calls. If each call you make is left over in the vicidial_auto_calls, and not just SOME of the calls your making then your call_log is not being pulled properly (or that would be my first guess).
Matt may have more to comment on the way to call the AGI itself.
Trevor
- tbenson
- Posts: 116
- Joined: Wed Mar 07, 2007 8:41 pm
- Location: California
by tbenson » Thu May 10, 2007 3:38 pm
Caspar,
From http://www.voip-info.org/wiki-Asterisk+cmd+AGI It looks like you are running a FastAGI method of calling the script. I beleive Vici has moved from call_log to a fast method, but i cannot find anyone using FastAGI (Run AGI remotely over TCP socket: agi://) in the method with the original call_log.agi.
Some of this is just recolection in reading the forums and wiki over the last week, so this may be vaguely mixed up issues in my head, but I would deffinately suggest changing the AGI(agi://127.0.0.1:4577/call_log) to AGI(call_log.agi). My assumption is if you make sure every dialplan aspect is updated (or backdated however you see it) to have an AGI line as shown. If you miss 1 dialplan with it, then at some point you will need to run the script provided earlier, or flush the table manually, as you will end up with orphans in the table from each of those calls.
Trevor
From http://www.voip-info.org/wiki-Asterisk+cmd+AGI It looks like you are running a FastAGI method of calling the script. I beleive Vici has moved from call_log to a fast method, but i cannot find anyone using FastAGI (Run AGI remotely over TCP socket: agi://) in the method with the original call_log.agi.
Some of this is just recolection in reading the forums and wiki over the last week, so this may be vaguely mixed up issues in my head, but I would deffinately suggest changing the AGI(agi://127.0.0.1:4577/call_log) to AGI(call_log.agi). My assumption is if you make sure every dialplan aspect is updated (or backdated however you see it) to have an AGI line as shown. If you miss 1 dialplan with it, then at some point you will need to run the script provided earlier, or flush the table manually, as you will end up with orphans in the table from each of those calls.
Trevor
- tbenson
- Posts: 116
- Joined: Wed Mar 07, 2007 8:41 pm
- Location: California
Related errors
by explidous » Wed May 16, 2007 12:07 pm
We have a more or less freshly setup system at one of our customer sites that has what looks like the same problem.
We did some deeper research and tests on it and we could see that depending on how the call was hung up the hangup extension would not finish executing.
We had put the Wait statement in the first line of the hangup extension to avoid tons of congestion messages for lines that were not fully released yet. After doing so we saw quite a number of calls getting stuck in autocalls. Investigating that deeper we found that the h,2, h,3, would never be called on a number of calls so the call would never get removed correctly and the hangup code would not be stored either.
After removing Wait() from the hangup extension the problem got somewhat better but still a number of calls did not make it to the second step in the dialplan there...
Since both actions are take in the same fast-agi script I just consolidated the two (patch will be uploaded once I looked into 2.0.3 to get it uptodate...) into just one deadAGI call which improved the result again, however there is still a number of calls that do not call the hangup extension at all!
All this tested on 1.2.18 with current zaptel, beta8 sangoma driver and all using ZAP.
Any suggestions?
We did some deeper research and tests on it and we could see that depending on how the call was hung up the hangup extension would not finish executing.
We had put the Wait statement in the first line of the hangup extension to avoid tons of congestion messages for lines that were not fully released yet. After doing so we saw quite a number of calls getting stuck in autocalls. Investigating that deeper we found that the h,2, h,3, would never be called on a number of calls so the call would never get removed correctly and the hangup code would not be stored either.
After removing Wait() from the hangup extension the problem got somewhat better but still a number of calls did not make it to the second step in the dialplan there...
Since both actions are take in the same fast-agi script I just consolidated the two (patch will be uploaded once I looked into 2.0.3 to get it uptodate...) into just one deadAGI call which improved the result again, however there is still a number of calls that do not call the hangup extension at all!
All this tested on 1.2.18 with current zaptel, beta8 sangoma driver and all using ZAP.
Any suggestions?
- explidous
- Posts: 22
- Joined: Fri Apr 13, 2007 5:00 pm
- Location: Germany
by mflorell » Thu May 17, 2007 2:30 am
I haven't noticed this problem on any of my systems(but I'm still running 1.2.17) At most, I've seen maybe 4 calls getting hung up on the hangup extension, and that's across 80,000 calls for an entire day with the load being very high. On servers with lower load it never happens.
What is the loadavg on the system when this happens?
Have you tried changing the parameters for the FastAGI server in astguiclient.conf?
What is the loadavg on the system when this happens?
Have you tried changing the parameters for the FastAGI server in astguiclient.conf?
- mflorell
- Site Admin
- Posts: 18387
- Joined: Wed Jun 07, 2006 2:45 pm
- Location: Florida
Load related
by explidous » Thu May 17, 2007 1:14 pm
I agree on the load related...
the load on that system is spiking periodically up to 10-12 but we see the lost hangups on lower loads as well. They however get way more when the load goes that high. I still see the problem that when the load gets high i also get some deadlock avoidance warnings which seem to be related to this as well.
The change log to 1.2.18 talks about optimizations in the hangup code to avoid deadlock... it locks like the optimization just skipps executing the rest of the hangup extension to avoid a deadlock....
The system we are seeing this on is a dual Xeon hyperthreaded, we moved mysql on a second box, which improved the situation but did not make it go away. load stays very low as long as call is not bridged to agent, however as soon as the first call is bridged it goes up... Asterisk is running on up to 300% CPU.
the load on that system is spiking periodically up to 10-12 but we see the lost hangups on lower loads as well. They however get way more when the load goes that high. I still see the problem that when the load gets high i also get some deadlock avoidance warnings which seem to be related to this as well.
The change log to 1.2.18 talks about optimizations in the hangup code to avoid deadlock... it locks like the optimization just skipps executing the rest of the hangup extension to avoid a deadlock....
The system we are seeing this on is a dual Xeon hyperthreaded, we moved mysql on a second box, which improved the situation but did not make it go away. load stays very low as long as call is not bridged to agent, however as soon as the first call is bridged it goes up... Asterisk is running on up to 300% CPU.
- explidous
- Posts: 22
- Joined: Fri Apr 13, 2007 5:00 pm
- Location: Germany
by mehdi » Thu May 17, 2007 1:38 pm
i have the same problem, my server is P4 3.2 HT, 2G Ram, mysql apache and asterisk, i use Sangoma 104D with last driver, asterisk 1.2.17.
And with 5 agents all go perfect, but with 7 agent we start having problems, the calls are not closed and the agent status appear incall.
and they have to logout to restart receiving calls.
we show that in vicidial_auto_calls the calls apear opened.
And with 5 agents all go perfect, but with 7 agent we start having problems, the calls are not closed and the agent status appear incall.
and they have to logout to restart receiving calls.
we show that in vicidial_auto_calls the calls apear opened.
Mehdi Chouikh
Universal Telcom Experts S.L
Universal Telcom Experts S.L
- mehdi
- Posts: 8
- Joined: Sun May 13, 2007 10:04 am
- Location: Spain
there are workarounds to get the agents unstuck...
by explidous » Thu May 17, 2007 3:30 pm
just run a script every minute that checks the calls in the vicidial_autocalls against the calls in live_channels and live_sip_channels whatever is left in autocalls and not in channels has already hungup and you have to handle it that way...
We use remote agents and patched it in VD_remoteagent but that only works for our "not normal" scenario so i did not post it jet.
We use remote agents and patched it in VD_remoteagent but that only works for our "not normal" scenario so i did not post it jet.
- explidous
- Posts: 22
- Joined: Fri Apr 13, 2007 5:00 pm
- Location: Germany
by mehdi » Fri May 18, 2007 4:30 am
thanks explidous, we have this working, but the problem is the script: is executed every minutes, and our agents have a complaint that they wait a lot for the next call.
looking on the log scripts, we show that agi VD_hangup is not executed when have more than 7 agents. is hangup extension problem, so thoday we will make some change in the agis.
and post the result.
looking on the log scripts, we show that agi VD_hangup is not executed when have more than 7 agents. is hangup extension problem, so thoday we will make some change in the agis.
and post the result.
Mehdi Chouikh
Universal Telcom Experts S.L
Universal Telcom Experts S.L
- mehdi
- Posts: 8
- Joined: Sun May 13, 2007 10:04 am
- Location: Spain
should not happen that often...
by explidous » Fri May 18, 2007 1:45 pm
I have the feeling it should not happen that often then...
When you are dialing for only 7 agents you might want to run that script maybe more often...
When you are dialing for only 7 agents you might want to run that script maybe more often...
- explidous
- Posts: 22
- Joined: Fri Apr 13, 2007 5:00 pm
- Location: Germany
by caspar » Thu Jun 21, 2007 6:01 am
I have change the AGI as recommended by T Benson, but it still gets stuck.
Thank you Chander Prakash. Your script seems to be working. I know this is not the right way to do it and I would like to know what is causing the problem, but at least the client is happy now.
Thank you Chander Prakash. Your script seems to be working. I know this is not the right way to do it and I would like to know what is causing the problem, but at least the client is happy now.
- caspar
- Posts: 111
- Joined: Thu Dec 21, 2006 6:55 am
- Location: South Africa
by scratchspace » Mon Jul 09, 2007 3:53 pm
I've run into the same problem (auto dials calls for a while then quits) and I believe there may still be a bug.
CentOS 4.5Asterisk SVN-branch-1.2-r72184M
FreePBX 2.2.2
Astguiclient 2.0.3
Vicidial VERSION: 2.0.95 BUILD: 70402-1157
VICIDIAL web-client version: 2.0.129 BUILD: 70322-1545
I've confirmed that the AGI scripts are being called correctly in the dialplan, when the call is placed, answered/transferred, and hungup. I've found two issues.
The first issue is that Asterisk generates unique IDs that are 15 digits long with a decimal leaving 4 trailing digits. The uniqueid column in the vicidial_auto_calls table provides for 18 digits with a decimal leaving 7 trailing digits. This results in a bogus unique ID being inserted into the database, usually ending in 000 or 001. When call_log.agi tries to delete the call from the vicidial_auto_calls, there is no match. This leaves a bunch of stale records behind. While I haven't tracked down the source of the erroneous digits, I think MySQL may be back filling them with random digits. My quick fix to this issue was to modify the column from "DOUBLE (18,7), to DOUBLE (15,4)". By making the above change, calls were properly cleaned up and the problem almost went away. I'm not convinced
this is the correct fix, I'll need Matt to chime in...
The second issue is that additional entries are being added to the vicidial_auto_calls table that never get cleaned up. I believe these entries should never be inserted in the first place. I don't know which program is inserting these entries (agi-VDADtransfer.agi ?) because they are not being logged to the agiout log. I do however see the unique IDs in the listen log. What happens is the unique ID of the originated call (DestUniqueID in listen log) is being logged into vicidial_auto_calls, but the unique ID that vicidial tracks (SrcUniqueID in listen log) is the only entry cleaned up (apparently by VD_hangup.agi). This issue, for now, requires the workaround script posted in Mantis ID 92 to be run every few minutes via cron. Perhaps there's some additional logging I've missed.
Below is the relevant cronological output from the agiout and listen logs.
|
2007-07-09 15:18:18|Event: Newchannel
Privilege: call,all
Channel: Local/8600068@default-3a5e,2
State: Ring
CallerID: <unknown>
CallerIDName: <unknown>
Uniqueid: 1184008718.4639
|
2007-07-09 15:18:18|Event: Newchannel
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
State: Down
CallerID: <unknown>
CallerIDName: <unknown>
Uniqueid: 1184008718.4638
Event: Newcallerid
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
CallerID: 8885551212
CallerIDName: M0709151838000603186
Uniqueid: 1184008718.4638
CID-CallingPres: 0 Presentation Allowed, Not Screened
Event: Newcallerid
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
CallerID: 8885551212
CallerIDName: M0709151838000603186
Uniqueid: 1184008718.4638
CID-CallingPres: 0 Presentation Allowed, Not Screened
Event: Newcallerid
Privilege: call,all
Channel: Local/8600068@default-3a5e,2
CallerID: 8885551212
CallerIDName: M0709151838000603186
Uniqueid: 1184008718.4639
CID-CallingPres: 0 Presentation Allowed, Not Screened
|
2007-07-09 15:18:18|Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,2
Context: default
Extension: 8600068
Priority: 1
Application: MeetMe
AppData: 8600068
Uniqueid: 1184008718.4639
Event: Newstate
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
State: Up
CallerID: 8885551212
CallerIDName: M0709151838000603186
Uniqueid: 1184008718.4638
Event: Newstate
Privilege: call,all
Channel: Local/8600068@default-3a5e,2
State: Up
CallerID: 8885551212
CallerIDName: M0709151838000603186
Uniqueid: 1184008718.4639
Event: MeetmeJoin
Privilege: call,all
Channel: Local/8600068@default-3a5e,2
Uniqueid: 1184008718.4639
Meetme: 8600068
Usernum: 2
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: default
Extension: 12165552468
Priority: 1
Application: Macro
AppData: dialout-trunk|1|12165552468||
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 1
Application: Set
AppData: DIAL_TRUNK=1
Uniqueid: 1184008718.4638
|
2007-07-09 15:18:18|Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 2
Application: Set
AppData: _NODEST=
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 3
Application: Set
AppData: DIAL_NUMBER=12165552468
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 4
Application: Set
AppData: ROUTE_PASSWD=
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 5
Application: Set
AppData: DIAL_TRUNK_OPTIONS=trw
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 6
Application: GotoIf
AppData: 1?noauth
Uniqueid: 1184008718.4638
|
2007-07-09 15:18:18|Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 8
Application: Set
AppData: GROUP =OUT_1
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 9
Application: Macro
AppData: user-callerid|SKIPTTL
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-user-callerid
Extension: s
Priority: 1
Application: NoOp
AppData: user-callerid: M0709151838000603186 8885551212
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-user-callerid
Extension: s
Priority: 2
Application: GotoIf
AppData: 1?report
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-user-callerid
Extension: s
Priority: 11
Application: NoOp
AppData: TTL: ARG1: SKIPTTL
Uniqueid: 1184008718.4638
|
2007-07-09 15:18:18|Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-user-callerid
Extension: s
Priority: 12
Application: GotoIf
AppData: 1?continue
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-user-callerid
Extension: s
Priority: 21
Application: NoOp
AppData: Using CallerID "M0709151838000603186" <8885551212>
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 10
Application: Macro
AppData: record-enable|8885551212|OUT
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-record-enable
Extension: s
Priority: 1
Application: GotoIf
AppData: 0?2:4
Uniqueid: 1184008718.4638
|
2007-07-09 15:18:18|Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-record-enable
Extension: s
Priority: 4
Application: DeadAGI
AppData: recordingcheck|20070709-151838|1184008718.4638
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-record-enable
Extension: s
Priority: 5
Application: NoOp
AppData: No recording needed
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 11
Application: GotoIf
AppData: 0?skipoutcid
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 12
Application: Set
AppData: DIAL_TRUNK_OPTIONS=tTwo
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 13
Application: GotoIf
AppData: 1?nomax
Uniqueid: 1184008718.4638
2007-07-09 15:18:38|call_log.agi| -- uniqueid = 1184008718.4638
2007-07-09 15:18:38|call_log.agi|AGI Variables: |1184008718.4638|Local/8600068@default-3a5e,1|s|Local|M0709151838000603186|
2007-07-09 15:18:38|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('1184008718.4638','Local/8600068@default-3a5e,1','','Local','10.0.10.50','s','','2007-07-09 15:18:38','1184008718','','','','','M0709151838000603186')|
|
2007-07-09 15:18:39|Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority:
|
2007-07-09 15:18:39|Event: Newstate
Privilege: call,all
Channel: SIP/voipprovider-087795a0
State: Ringing
CallerID: 8885551212
CallerIDName: M0709151838000603186
Uniqueid: 1184008718.4640
|
2007-07-09 15:18:47|Event: Newstate
Privilege: call,all
Channel: SIP/voipprovider-087795a0
State: Up
CallerID: 8885551212
CallerIDName: M0709151838000603186
Uniqueid: 1184008718.4640
|
2007-07-09 15:18:47|Event: Link
Privilege: call,all
Channel1: Local/8600068@default-3a5e,1
Channel2: SIP/voipprovider-087795a0
Uniqueid1: 1184008718.4638
Uniqueid2: 1184008718.4640
CallerID1: 8885551212
CallerID2: 8885551212
|
2007-07-09 15:19:09|Event: Unlink
Privilege: call,all
Channel1: Local/8600068@default-3a5e,1
Channel2: SIP/voipprovider-087795a0
Uniqueid1: 1184008718.4638
Uniqueid2: 1184008718.4640
CallerID1: 8885551212
CallerID2: 8885551212
Event: Hangup
Privilege: call,all
Channel: SIP/voipprovider-087795a0
Uniqueid: 1184008718.4640
Cause: 16
Cause-txt: Normal Clearing
Event: Hangup
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Uniqueid: 1184008718.4638
Cause: 16
Cause-txt: Normal Clearing
|
2007-07-09 15:19:09|Event: MeetmeLeave
Privilege: call,all
Channel: Local/8600068@default-3a5e,2
Uniqueid: 1184008718.4639
Meetme: 8600068
Usernum: 2
|
2007-07-09 15:19:09|Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,2
Context: default
Extension: h
Priority: 1
Application: DeadAGI
AppData: call_log.agi|h
Uniqueid: 1184008718.4639
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,2
Context: default
Extension: h
Priority: 2
Application: DeadAGI
AppData: VD_hangup.agi|PRI-----NODEBUG-----0---------------
Uniqueid: 1184008718.4639
|
2007-07-09 15:19:09|Event: Hangup
Privilege: call,all
Channel: Local/8600068@default-3a5e,2
Uniqueid: 1184008718.4639
Cause: 0
Cause-txt: Unknown
2007-07-09 15:19:10|call_log.agi| -- uniqueid = 1184008718.4639
2007-07-09 15:19:10|call_log.agi|AGI Variables: |1184008718.4639|Local/8600068@default-3a5e,2|h|Local|M0709151838000603186|
2007-07-09 15:19:10|call_log.agi||DELETE from live_inbound where uniqueid='1184008718.4639' and server_ip='10.0.10.50'|
2007-07-09 15:19:10|call_log.agi|+++++ CALL LOG HUNGUP: |1184008718.4639|Local/8600068@default-3a5e,2|h|2007-07-09 15:19:10|min: |
2007-07-09 15:19:10|VD_hangup.agi| -- uniqueid = 1184008718.4639
2007-07-09 15:19:10|VD_hangup.agi|AGI Variables: |1184008718.4639|Local/8600068@default-3a5e,2|h|Local|M0709151838000603186|
CentOS 4.5Asterisk SVN-branch-1.2-r72184M
FreePBX 2.2.2
Astguiclient 2.0.3
Vicidial VERSION: 2.0.95 BUILD: 70402-1157
VICIDIAL web-client version: 2.0.129 BUILD: 70322-1545
I've confirmed that the AGI scripts are being called correctly in the dialplan, when the call is placed, answered/transferred, and hungup. I've found two issues.
The first issue is that Asterisk generates unique IDs that are 15 digits long with a decimal leaving 4 trailing digits. The uniqueid column in the vicidial_auto_calls table provides for 18 digits with a decimal leaving 7 trailing digits. This results in a bogus unique ID being inserted into the database, usually ending in 000 or 001. When call_log.agi tries to delete the call from the vicidial_auto_calls, there is no match. This leaves a bunch of stale records behind. While I haven't tracked down the source of the erroneous digits, I think MySQL may be back filling them with random digits. My quick fix to this issue was to modify the column from "DOUBLE (18,7), to DOUBLE (15,4)". By making the above change, calls were properly cleaned up and the problem almost went away. I'm not convinced
this is the correct fix, I'll need Matt to chime in...
The second issue is that additional entries are being added to the vicidial_auto_calls table that never get cleaned up. I believe these entries should never be inserted in the first place. I don't know which program is inserting these entries (agi-VDADtransfer.agi ?) because they are not being logged to the agiout log. I do however see the unique IDs in the listen log. What happens is the unique ID of the originated call (DestUniqueID in listen log) is being logged into vicidial_auto_calls, but the unique ID that vicidial tracks (SrcUniqueID in listen log) is the only entry cleaned up (apparently by VD_hangup.agi). This issue, for now, requires the workaround script posted in Mantis ID 92 to be run every few minutes via cron. Perhaps there's some additional logging I've missed.
Below is the relevant cronological output from the agiout and listen logs.
|
2007-07-09 15:18:18|Event: Newchannel
Privilege: call,all
Channel: Local/8600068@default-3a5e,2
State: Ring
CallerID: <unknown>
CallerIDName: <unknown>
Uniqueid: 1184008718.4639
|
2007-07-09 15:18:18|Event: Newchannel
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
State: Down
CallerID: <unknown>
CallerIDName: <unknown>
Uniqueid: 1184008718.4638
Event: Newcallerid
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
CallerID: 8885551212
CallerIDName: M0709151838000603186
Uniqueid: 1184008718.4638
CID-CallingPres: 0 Presentation Allowed, Not Screened
Event: Newcallerid
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
CallerID: 8885551212
CallerIDName: M0709151838000603186
Uniqueid: 1184008718.4638
CID-CallingPres: 0 Presentation Allowed, Not Screened
Event: Newcallerid
Privilege: call,all
Channel: Local/8600068@default-3a5e,2
CallerID: 8885551212
CallerIDName: M0709151838000603186
Uniqueid: 1184008718.4639
CID-CallingPres: 0 Presentation Allowed, Not Screened
|
2007-07-09 15:18:18|Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,2
Context: default
Extension: 8600068
Priority: 1
Application: MeetMe
AppData: 8600068
Uniqueid: 1184008718.4639
Event: Newstate
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
State: Up
CallerID: 8885551212
CallerIDName: M0709151838000603186
Uniqueid: 1184008718.4638
Event: Newstate
Privilege: call,all
Channel: Local/8600068@default-3a5e,2
State: Up
CallerID: 8885551212
CallerIDName: M0709151838000603186
Uniqueid: 1184008718.4639
Event: MeetmeJoin
Privilege: call,all
Channel: Local/8600068@default-3a5e,2
Uniqueid: 1184008718.4639
Meetme: 8600068
Usernum: 2
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: default
Extension: 12165552468
Priority: 1
Application: Macro
AppData: dialout-trunk|1|12165552468||
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 1
Application: Set
AppData: DIAL_TRUNK=1
Uniqueid: 1184008718.4638
|
2007-07-09 15:18:18|Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 2
Application: Set
AppData: _NODEST=
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 3
Application: Set
AppData: DIAL_NUMBER=12165552468
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 4
Application: Set
AppData: ROUTE_PASSWD=
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 5
Application: Set
AppData: DIAL_TRUNK_OPTIONS=trw
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 6
Application: GotoIf
AppData: 1?noauth
Uniqueid: 1184008718.4638
|
2007-07-09 15:18:18|Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 8
Application: Set
AppData: GROUP =OUT_1
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 9
Application: Macro
AppData: user-callerid|SKIPTTL
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-user-callerid
Extension: s
Priority: 1
Application: NoOp
AppData: user-callerid: M0709151838000603186 8885551212
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-user-callerid
Extension: s
Priority: 2
Application: GotoIf
AppData: 1?report
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-user-callerid
Extension: s
Priority: 11
Application: NoOp
AppData: TTL: ARG1: SKIPTTL
Uniqueid: 1184008718.4638
|
2007-07-09 15:18:18|Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-user-callerid
Extension: s
Priority: 12
Application: GotoIf
AppData: 1?continue
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-user-callerid
Extension: s
Priority: 21
Application: NoOp
AppData: Using CallerID "M0709151838000603186" <8885551212>
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 10
Application: Macro
AppData: record-enable|8885551212|OUT
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-record-enable
Extension: s
Priority: 1
Application: GotoIf
AppData: 0?2:4
Uniqueid: 1184008718.4638
|
2007-07-09 15:18:18|Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-record-enable
Extension: s
Priority: 4
Application: DeadAGI
AppData: recordingcheck|20070709-151838|1184008718.4638
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-record-enable
Extension: s
Priority: 5
Application: NoOp
AppData: No recording needed
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 11
Application: GotoIf
AppData: 0?skipoutcid
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 12
Application: Set
AppData: DIAL_TRUNK_OPTIONS=tTwo
Uniqueid: 1184008718.4638
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority: 13
Application: GotoIf
AppData: 1?nomax
Uniqueid: 1184008718.4638
2007-07-09 15:18:38|call_log.agi| -- uniqueid = 1184008718.4638
2007-07-09 15:18:38|call_log.agi|AGI Variables: |1184008718.4638|Local/8600068@default-3a5e,1|s|Local|M0709151838000603186|
2007-07-09 15:18:38|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('1184008718.4638','Local/8600068@default-3a5e,1','','Local','10.0.10.50','s','','2007-07-09 15:18:38','1184008718','','','','','M0709151838000603186')|
|
2007-07-09 15:18:39|Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Context: macro-dialout-trunk
Extension: s
Priority:
|
2007-07-09 15:18:39|Event: Newstate
Privilege: call,all
Channel: SIP/voipprovider-087795a0
State: Ringing
CallerID: 8885551212
CallerIDName: M0709151838000603186
Uniqueid: 1184008718.4640
|
2007-07-09 15:18:47|Event: Newstate
Privilege: call,all
Channel: SIP/voipprovider-087795a0
State: Up
CallerID: 8885551212
CallerIDName: M0709151838000603186
Uniqueid: 1184008718.4640
|
2007-07-09 15:18:47|Event: Link
Privilege: call,all
Channel1: Local/8600068@default-3a5e,1
Channel2: SIP/voipprovider-087795a0
Uniqueid1: 1184008718.4638
Uniqueid2: 1184008718.4640
CallerID1: 8885551212
CallerID2: 8885551212
|
2007-07-09 15:19:09|Event: Unlink
Privilege: call,all
Channel1: Local/8600068@default-3a5e,1
Channel2: SIP/voipprovider-087795a0
Uniqueid1: 1184008718.4638
Uniqueid2: 1184008718.4640
CallerID1: 8885551212
CallerID2: 8885551212
Event: Hangup
Privilege: call,all
Channel: SIP/voipprovider-087795a0
Uniqueid: 1184008718.4640
Cause: 16
Cause-txt: Normal Clearing
Event: Hangup
Privilege: call,all
Channel: Local/8600068@default-3a5e,1
Uniqueid: 1184008718.4638
Cause: 16
Cause-txt: Normal Clearing
|
2007-07-09 15:19:09|Event: MeetmeLeave
Privilege: call,all
Channel: Local/8600068@default-3a5e,2
Uniqueid: 1184008718.4639
Meetme: 8600068
Usernum: 2
|
2007-07-09 15:19:09|Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,2
Context: default
Extension: h
Priority: 1
Application: DeadAGI
AppData: call_log.agi|h
Uniqueid: 1184008718.4639
Event: Newexten
Privilege: call,all
Channel: Local/8600068@default-3a5e,2
Context: default
Extension: h
Priority: 2
Application: DeadAGI
AppData: VD_hangup.agi|PRI-----NODEBUG-----0---------------
Uniqueid: 1184008718.4639
|
2007-07-09 15:19:09|Event: Hangup
Privilege: call,all
Channel: Local/8600068@default-3a5e,2
Uniqueid: 1184008718.4639
Cause: 0
Cause-txt: Unknown
2007-07-09 15:19:10|call_log.agi| -- uniqueid = 1184008718.4639
2007-07-09 15:19:10|call_log.agi|AGI Variables: |1184008718.4639|Local/8600068@default-3a5e,2|h|Local|M0709151838000603186|
2007-07-09 15:19:10|call_log.agi||DELETE from live_inbound where uniqueid='1184008718.4639' and server_ip='10.0.10.50'|
2007-07-09 15:19:10|call_log.agi|+++++ CALL LOG HUNGUP: |1184008718.4639|Local/8600068@default-3a5e,2|h|2007-07-09 15:19:10|min: |
2007-07-09 15:19:10|VD_hangup.agi| -- uniqueid = 1184008718.4639
2007-07-09 15:19:10|VD_hangup.agi|AGI Variables: |1184008718.4639|Local/8600068@default-3a5e,2|h|Local|M0709151838000603186|
- scratchspace
- Posts: 26
- Joined: Wed Sep 13, 2006 12:51 pm
by scratchspace » Wed Jul 11, 2007 1:04 pm
In regards to the first issue I previously reported, it became clear today that shortening the length of the uniqueid column in the vicidial_auto_calls table is not the correct solution. Today the trailing digits in the uniqueid generated by Asterisk increased from 4 digits to 5, and I suspect this will increase again in a few days.
This gets back to the issue I suspected and now confirmed, that MySQL is padding the trailing digits in the uniqueid column. If the unique ID is 1184176800.2481, it will be inserted as 1184176800.2481000. Changing the column type from DOUBLE to VARCHAR would address this, but I suspect there would be a performance hit.
Matt, do you have any suggestions as to how we can best resolve this issue?
This gets back to the issue I suspected and now confirmed, that MySQL is padding the trailing digits in the uniqueid column. If the unique ID is 1184176800.2481, it will be inserted as 1184176800.2481000. Changing the column type from DOUBLE to VARCHAR would address this, but I suspect there would be a performance hit.
Matt, do you have any suggestions as to how we can best resolve this issue?
- scratchspace
- Posts: 26
- Joined: Wed Sep 13, 2006 12:51 pm
by mflorell » Mon Jul 16, 2007 8:54 am
uniqueID will work as a VARCHAR actually, the BRIstufft Asterisk users already have to do this because their uniqueIDs show up as machinename-uniqueid so I recommend changing them all to VARCHAR(40).
give changing it to VARCHAR a try and post if it resolves the problem or not.
As for performance hit, I believe DOUBLEs are stored as specially formatted VARCHARs anyway.
ALTER TABLE live_inbound MODIFY uniqueid VARCHAR(40) NOT NULL;
ALTER TABLE live_inbound_log MODIFY uniqueid VARCHAR(40) NOT NULL;
ALTER TABLE live_inbound_log MODIFY uniqueid VARCHAR(40) NOT NULL;
ALTER TABLE vicidial_manager MODIFY uniqueid VARCHAR(40) NOT NULL;
ALTER TABLE vicidial_live_agents MODIFY uniqueid VARCHAR(40) NOT NULL;
ALTER TABLE vicidial_auto_calls MODIFY uniqueid VARCHAR(40) NOT NULL;
ALTER TABLE call_log DROP PRIMARY KEY;
ALTER TABLE call_log DROP INDEX uniqueid;
ALTER TABLE call_log MODIFY uniqueid VARCHAR(40) PRIMARY KEY UNIQUE NOT NULL;
ALTER TABLE park_log DROP PRIMARY KEY;
ALTER TABLE park_log DROP INDEX uniqueid;
ALTER TABLE park_log MODIFY uniqueid VARCHAR(40) PRIMARY KEY UNIQUE NOT NULL;
ALTER TABLE vicidial_log DROP PRIMARY KEY;
ALTER TABLE vicidial_log DROP INDEX uniqueid;
ALTER TABLE vicidial_log MODIFY uniqueid VARCHAR(40) PRIMARY KEY UNIQUE NOT NULL;
give changing it to VARCHAR a try and post if it resolves the problem or not.
As for performance hit, I believe DOUBLEs are stored as specially formatted VARCHARs anyway.
ALTER TABLE live_inbound MODIFY uniqueid VARCHAR(40) NOT NULL;
ALTER TABLE live_inbound_log MODIFY uniqueid VARCHAR(40) NOT NULL;
ALTER TABLE live_inbound_log MODIFY uniqueid VARCHAR(40) NOT NULL;
ALTER TABLE vicidial_manager MODIFY uniqueid VARCHAR(40) NOT NULL;
ALTER TABLE vicidial_live_agents MODIFY uniqueid VARCHAR(40) NOT NULL;
ALTER TABLE vicidial_auto_calls MODIFY uniqueid VARCHAR(40) NOT NULL;
ALTER TABLE call_log DROP PRIMARY KEY;
ALTER TABLE call_log DROP INDEX uniqueid;
ALTER TABLE call_log MODIFY uniqueid VARCHAR(40) PRIMARY KEY UNIQUE NOT NULL;
ALTER TABLE park_log DROP PRIMARY KEY;
ALTER TABLE park_log DROP INDEX uniqueid;
ALTER TABLE park_log MODIFY uniqueid VARCHAR(40) PRIMARY KEY UNIQUE NOT NULL;
ALTER TABLE vicidial_log DROP PRIMARY KEY;
ALTER TABLE vicidial_log DROP INDEX uniqueid;
ALTER TABLE vicidial_log MODIFY uniqueid VARCHAR(40) PRIMARY KEY UNIQUE NOT NULL;
- mflorell
- Site Admin
- Posts: 18387
- Joined: Wed Jun 07, 2006 2:45 pm
- Location: Florida
by scratchspace » Mon Jul 16, 2007 1:31 pm
I tried modifying only the vicidial_auto_calls table and it still seems to pad the uniqueid. Is this the result of values pulled from other tables that need their column types redefined? Just a little skittish about changing all of these tables...
- scratchspace
- Posts: 26
- Joined: Wed Sep 13, 2006 12:51 pm
by mflorell » Mon Jul 16, 2007 5:27 pm
I have tested the changes in production and they do work, you should test off-hours of course. Your issue might be caused by another column, and you should change them all at once or it will not work properly.
- mflorell
- Site Admin
- Posts: 18387
- Joined: Wed Jun 07, 2006 2:45 pm
- Location: Florida
by scratchspace » Thu Jul 26, 2007 12:18 pm
Matt, changing the column to VARCHAR has solved the first problem I reported. What about the second problem (post Mon Jul 09, 2007 12:53 pm)? I still need to run the cleanup script every minute to clear out the other entries.
- scratchspace
- Posts: 26
- Joined: Wed Sep 13, 2006 12:51 pm
by aster1 » Thu Jul 26, 2007 1:57 pm
Matt i had vicidial 2.0.2 and 2.0.3 both versions installed at different locations doing outbound dialing over sip and i had this dialer getting stuck problem since start .. running that cleanup scriipt every minute or two works great .
Btw i ran that mysql query to convert fields to varchar in vicidial 2.0.3 and i still had calls stuck in table .. so i am running that cleanup script still . I think this problem is more frustrating when less number of agents are dialing ( like 7-10 ) so few calls stuck also make lot of difference .. if there are more number of agents it takes longer time for many calls to get stuck and stop auto dialing completely . Btw when this happens the realtime screen always shows X number of calls being placed ... and there are X number of entried in vicidial_auto_calls table but none is being dialed in asterisk
Btw i ran that mysql query to convert fields to varchar in vicidial 2.0.3 and i still had calls stuck in table .. so i am running that cleanup script still . I think this problem is more frustrating when less number of agents are dialing ( like 7-10 ) so few calls stuck also make lot of difference .. if there are more number of agents it takes longer time for many calls to get stuck and stop auto dialing completely . Btw when this happens the realtime screen always shows X number of calls being placed ... and there are X number of entried in vicidial_auto_calls table but none is being dialed in asterisk
- aster1
- Posts: 281
- Joined: Sun Dec 24, 2006 6:48 am
- Location: India
by mflorell » Fri Jul 27, 2007 9:18 am
Is there a pattern to the calls that get stuck in vicidial_auto_calls?
Are they numbers that fit within the dialplan?
I have many systems up and running in many different locations, and I have never seen this behavour at any of them, so it is hard for me to test fixes since I cannot duplicate the problem.
Are they numbers that fit within the dialplan?
I have many systems up and running in many different locations, and I have never seen this behavour at any of them, so it is hard for me to test fixes since I cannot duplicate the problem.
- mflorell
- Site Admin
- Posts: 18387
- Joined: Wed Jun 07, 2006 2:45 pm
- Location: Florida
26 posts
• Page 1 of 1
Who is online
Users browsing this forum: Google [Bot] and 154 guests