vicidial.org

One of our clients has noted that sometimes, the message "You can only disposition a call once" appears when applying disposition to a call. We understand that the error means that somehow, the call has already been disposed, so we went to the lead search and looked at the lead records, and found this:



As you can notice, the same lead is disposed twice by the same agent.

I dug further, and found in the vicidial_log table that this lead has 2 calls with different uniqueids: one being 1418078077.032811680 and the other being 1418078078.032811680.

The call was made manually, since its record appears in the user_call_log.


This happens with different agents, workstations and campaigns, and occurs at random. The only common thing I can find is that all campaigns dial manually.

Any ideas on where to look for this solution?

I have heard from one other manual dial client that this happens sometimes, but we have not been able to find a cause for it.

You say that there are 2 separate calls in the vicidial_log table, can you actually see two different calls being placed in the Asterisk CLI when this happens?(or in the screeenlog.0 file?)

Have you found any reliable way to replicate this problem?

Matt,

No, I can´t replicate the problem. Client says it occurs very randomly, and so far I haven´t been able to find 2 calls at the screenlog due to time between the error occuring and the report being received.

I´ll ask for a new report to find the log for this, and I´ll update this thread when I have that information.

Same here, this started when we upgrade 10 days ago when we upgrade to SVN 2238

VERSION: 2.10-464a
BUILD: 150101-1511

Mine is slightly older:

VERSION: 2.10-459a
BUILD: 141204-0559

I´m still waiting for a new report to check the screenlog and I´ll post results. Gabriel, would be nice if you do the same.

We have this same thing happening. We were using an older (2013) version and never had the problem in 2 years, but since we upgraded, we very randomly get this error. It's an endless loop (Agent clicks OK and the same message pops right back up) and forces us to force log the agent out. The calls log results in "DISPO" status and the vicidial_list status gets turned into "ERI".

I'm not sure if it's related but in all of our campaigns we utilize the agent API to disp calls.

We're using: Vicibox 4.0.1 install CD (Asterisk 1.4.44) upgraded to : VERSION: 2.12-480a, BUILD: 150404-0932

That issue should have been fixed in svn/trunk at the end of January 2015, at least for the two clients that had that problem the changes we made then fixed it for them.

Interesting. The problem may be similar to but not the same then. This is happening on both manual and adapt dialed campaigns for us. It's also happening on two separate installations. One is a 4 server cluster running 150422-1953. The other is a single server running 150404-0932. Both are upgrades from Vicibox 4.0.1.

In more detail, we send a PHP API call to hang up and disp each call. Normally the green disposition screen will "flash" for the agent when everything works properly and then they will go onto their next call. However when the error happens, the calls will disconnect and the green disposition screen will stay on the screen and not disappear. Then if the agent tries to click on any disposition, they get stuck in the "you can only disposition a call once" error. This randomly happens, most calls do not have the error. I checked the vicidial_api_log table and the API calls are resulting in success. Is there anything else you can point me to to look at? Thanks!

I haven't seen this issue since we fixed it in January, and it was hard to reproduce even then.

The success that you see from the API simply means that it was accepted, not that it was executed.

At this point in the code, the only way that message can come up is if the DispoSelect_submit javascript function is called after the lead_id hidden form field is cleared out, and that only happens with the ManualDialSkip and DispoSelect_submit functions. So, it might be that somehow the API trigger is being run twice, although I don't know of any easy way to check for that.

Exactly how frequently is this happening?

It happened probably half a dozen times yesterday in various campaigns out of about 30k calls.
It was also reported to me that on the adapt campaign, after the API is triggered, it brought up the error and the rep received another call which she was unable to do anything with because the screen was still on the green disposition screen and giving the error message.

I believe our API call is correct? (it's worked for years before upgrade and most calls still):

Code: Select all

$status = $_POST['status'];
$update = file_get_contents("http://$webip/agc/api.php?source=$campaign&user=6666&pass=ourpassword&agent_user=$user&function=external_hangup&value=1");
$update2 = file_get_contents("http://$webip/agc/api.php?source=$campaign&user=6666&pass=ourpassword&agent_user=$user&function=external_status&value=$status");


Thanks!

It's very difficult to troubleshoot something that happens 0.02% of the time.

Are there any patterns to the people that are affected?

Your code looks fine from what I can tell.

So far we haven't found any pattern although we're certainly on the lookout.

One thing I noticed after upgrading is that we're getting a lot of mysqli errors. I"m not sure if they are somehow related, but here is a small snippet. They're all the same.

Code: Select all

2015-05-01 16:17:20|vdc_db_query|00280|1062|Duplicate entry '1430514987.257370' for key 'PRIMARY'|INSERT INTO vicidial_log (uniqueid,lead_id,list_id,campaign_id,call_date,start_epoch,status,phone_code,phone_number,user,comments,processed,user_group,alt_dial,called_count) values('1430514987.257370','935754','331162','PROGRAM1','2015-05-01 16:17:20','1430515040','DONEM','1','7204043348','14519','MANUAL','N','OUTBOUNDREPS','MAIN','1');|14519|172.24.98.87|1430514805_22611028478|
2015-05-01 16:20:06|vdc_db_query|00279|1062|Duplicate entry '1430515197.257914' for key 'PRIMARY'|INSERT INTO vicidial_log (uniqueid,lead_id,list_id,campaign_id,call_date,start_epoch,status,phone_code,phone_number,user,comments,processed,user_group,alt_dial,called_count) values('1430515197.257914','937469','331162','PROGRAM1','2015-05-01 16:20:06','1430515206','INCALL','1','9496837470','SA576','MANUAL','N','OUTBOUNDREPS','MAIN','1');|SA576|172.24.98.87|1430514002_60315010187|
2015-05-01 16:25:07|vdc_db_query|00279|1062|Duplicate entry '1430515497.258691' for key 'PRIMARY'|INSERT INTO vicidial_log (uniqueid,lead_id,list_id,campaign_id,call_date,start_epoch,status,phone_code,phone_number,user,comments,processed,user_group,alt_dial,called_count) values('1430515497.258691','931406','331162','PROGRAM1','2015-05-01 16:25:07','1430515507','INCALL','1','3033177244','SA309','MANUAL','N','OUTBOUNDREPS','MAIN','1');|SA309|172.24.98.87|1430515108_60614188754|
2015-05-01 16:25:42|vdc_db_query|00280|1062|Duplicate entry '1430515464.258579' for key 'PRIMARY'|INSERT INTO vicidial_log (uniqueid,lead_id,list_id,campaign_id,call_date,start_epoch,status,phone_code,phone_number,user,comments,processed,user_group,alt_dial,called_count) values('1430515464.258579','936483','331162','PROGRAM1','2015-05-01 16:25:42','1430515542','DONEM','1','7206418538','SA365','MANUAL','N','OUTBOUNDREPS','MAIN','1');|SA365|172.24.98.87|1430514921_60416646542|
2015-05-01 16:55:07|vdc_db_query|00279|1062|Duplicate entry '1430517300.262472' for key 'PRIMARY'|INSERT INTO vicidial_log (uniqueid,lead_id,list_id,campaign_id,call_date,start_epoch,status,phone_code,phone_number,user,comments,processed,user_group,alt_dial,called_count) values('1430517300.262472','934236','331162','PROGRAM1','2015-05-01 16:55:07','1430517307','INCALL','1','7196455673','14191','MANUAL','N','OUTBOUNDREPS','MAIN','2');|14191|172.24.98.87|1430516782_30517718427|
2015-05-01 16:56:20|vdc_db_query|00280|1062|Duplicate entry '1430517269.262346' for key 'PRIMARY'|INSERT INTO vicidial_log (uniqueid,lead_id,list_id,campaign_id,call_date,start_epoch,status,phone_code,phone_number,user,comments,processed,user_group,alt_dial,called_count) values('1430517269.262346','934468','331162','PROGRAM1','2015-05-01 16:56:20','1430517380','DONEM','1','7202277352','SA681','MANUAL','N','OUTBOUNDREPS','MAIN','2');|SA681|172.24.98.87|1430516679_62217886455|
2015-05-01 17:00:07|vdc_db_query|00279|1062|Duplicate entry '1430517574.263471' for key 'PRIMARY'|INSERT INTO vicidial_log (uniqueid,lead_id,list_id,campaign_id,call_date,start_epoch,status,phone_code,phone_number,user,comments,processed,user_group,alt_dial,called_count) values('1430517574.263471','934993','331162','CPG5120B','2015-05-01 17:00:07','1430517607','INCALL','1','7202969952','SA550','MANUAL','N','OUTBOUNDREPS','MAIN','2');|SA550|172.24.98.87|1430516252_61612759003|
2015-05-01 17:00:07|vdc_db_query|00279|1062|Duplicate entry '1430517569.263456' for key 'PRIMARY'|INSERT INTO vicidial_log (uniqueid,lead_id,list_id,campaign_id,call_date,start_epoch,status,phone_code,phone_number,user,comments,processed,user_group,alt_dial,called_count) values('1430517569.263456','933392','331162','PROGRAM1','2015-05-01 17:00:07','1430517607','INCALL','1','3212437383','14474','MANUAL','N','OUTBOUNDREPS','MAIN','2');|14474|172.24.98.87|1430517565_22210327995|
2015-05-01 17:09:21|vdc_db_query|00279|1062|Duplicate entry '1430518158.265733' for key 'PRIMARY'|INSERT INTO vicidial_log (uniqueid,lead_id,list_id,campaign_id,call_date,start_epoch,status,phone_code,phone_number,user,comments,processed,user_group,alt_dial,called_count) values('1430518158.265733','933832','331162','PROGRAM1','2015-05-01 17:09:21','1430518161','INCALL','1','5852699528','SA509','MANUAL','N','OUTBOUNDREPS','MAIN','2');|SA509|172.24.98.87|1430517672_60814847688|
2015-05-01 17:18:32|vdc_db_query|00279|1062|Duplicate entry '1430518709.268102' for key 'PRIMARY'|INSERT INTO vicidial_log (uniqueid,lead_id,list_id,campaign_id,call_date,start_epoch,status,phone_code,phone_number,user,comments,processed,user_group,alt_dial,called_count) values('1430518709.268102','931176','331162','PROGRAM1','2015-05-01 17:18:32','1430518712','INCALL','1','2409971036','14519','MANUAL','N','OUTBOUNDREPS','MAIN','2');|14519|172.24.98.87|1430518682_22612138658|
2015-05-01 17:20:06|vdc_db_query|00279|1062|Duplicate entry '1430518793.268456' for key 'PRIMARY'|INSERT INTO vicidial_log (uniqueid,lead_id,list_id,campaign_id,call_date,start_epoch,status,phone_code,phone_number,user,comments,processed,user_group,alt_dial,called_count) values('1430518793.268456','936102','331162','PROGRAM1','2015-05-01 17:20:06','1430518806','INCALL','1','7204724815','14496','MANUAL','N','OUTBOUNDREPS','MAIN','2');|14496|172.24.98.87|1430516796_22819222086|
2015-05-01 17:20:06|vdc_db_query|00279|1062|Duplicate entry '1430518793.268456' for key 'PRIMARY'|INSERT INTO vicidial_log (uniqueid,lead_id,list_id,campaign_id,call_date,start_epoch,status,phone_code,phone_number,user,comments,processed,user_group,alt_dial,called_count) values('1430518793.268456','936102','331162','PROGRAM1','2015-05-01 17:20:06','1430518806','INCALL','1','7204724815','14496','MANUAL','N','OUTBOUNDREPS','MAIN','2');|14496|172.24.98.87|1430516796_22819222086|
2015-05-01 17:32:21|vdc_db_query|00279|1062|Duplicate entry '1430519537.271640' for key 'PRIMARY'|INSERT INTO vicidial_log (uniqueid,lead_id,list_id,campaign_id,call_date,start_epoch,status,phone_code,phone_number,user,comments,processed,user_group,alt_dial,called_count) values('1430519537.271640','937278','331162','PROGRAM1','2015-05-01 17:32:21','1430519541','INCALL','1','8473704926','SA452','MANUAL','N','OUTBOUNDREPS','MAIN','2');|SA452|172.24.98.87|1430516310_62315684894|
2015-05-01 17:39:43|vdc_db_query|00279|1062|Duplicate entry '1430519976.273434' for key 'PRIMARY'|INSERT INTO vicidial_log (uniqueid,lead_id,list_id,campaign_id,call_date,start_epoch,status,phone_code,phone_number,user,comments,processed,user_group,alt_dial,called_count) values('1430519976.273434','932103','331162','PROGRAM1','2015-05-01 17:39:43','1430519983','INCALL','1','3035947251','SA365','MANUAL','N','OUTBOUNDREPS','MAIN','2');|SA365|172.24.98.87|1430519496_60414763874|
2015-05-01 17:40:08|vdc_db_query|00279|1062|Duplicate entry '1430519999.273503' for key 'PRIMARY'|INSERT INTO vicidial_log (uniqueid,lead_id,list_id,campaign_id,call_date,start_epoch,status,phone_code,phone_number,user,comments,processed,user_group,alt_dial,called_count) values('1430519999.273503','933109','331162','PROGRAM1','2015-05-01 17:40:08','1430520008','INCALL','1','3039361777','SA509','MANUAL','N','OUTBOUNDREPS','MAIN','2');|SA509|172.24.98.87|1430517672_60814847688|

Would it be possible that the PHP version (5.3. of Vicibox 4.0.1 install just isn't working right with the latest code? If you think it's possible, I'll fire up a new installation and backup to it to test.

Another weird thing that's happening (which I'm not sure is related either) is that when we get an inbound call, we use CIDLOOKUP on the DID's. When a lead is matched, it's changing the list ID of that lead to the campaign the rep is currently logged into. For example, rep is logged into CAMPAIGN1 and gets inbound call, which is matched to a list in CAMPAIGN5. The call goes through fine but then that lead now has the list ID of the list in CAMPAIGN1. We have no custom PHP end/start call URLs. If we click on "See a list of recordings and calls for this DID" (user_stats.php?DB=&did_id=2284&did=1) Every single entry shows either a "0" or an invalid leadID, a number that is far off from the real lead ID that it was matched to and isn't even a real leadid in our system.

I know you're busy. Thanks for any suggestions!

Those errors are usually normal, we haven't tied any issues to them in the past.

The PHP version may be an issue, but I don't think we've tied any specific issues to that version of PHP.

If a lead is matched with CIDLOOKUP, it should be preserving the list_id of the original lead. If it is not matched, then it should use the list_id that you set in the DID to use, not a campaign-setting list_id.