vicidial.org

Hi guys, I just want to know if anyone has the same scenario that I've encountered with inbound calls.

Vicidial:
ViciBox: v.7.0.4-170113
VERSION: 2.14-585a
BUILD: 170114-1356

My problem is that sometimes, inbound call is considered as a "Dead Call" according to the code in agc/vicidial.php.
This problem is intermittent, and I just want to know if there are any modifications that I could do in order for this problem doesn't occur.

Agents are reporting that from the agc screen, it's showing "Hangup Call" but the customer is still on the line.
I checked it and called the system myself a few times and merely got a pattern.

First, I was counting whether it makes a pattern in which the number of times the inbound call comes, it will be considered as a "Dead Call". But it wasn't, instead, I put a logger in agc/vicidial.php and see where it lands.
The log output was from the condition in which vicidial checks for "Dead Calls".

My suspect is that the conf_exten_check.php is giving false data or somewhat like a delay for some reason?
I am still investigating whether this problem is from conf_exten_check.php api or from other else.

I hope anyone could give me some insights or a fix for this one.

Here is my campaign Dial Method setup:

I found out from conf_exten_check.php->refresh() method:
When checking for dead calls, it will get the current agent's call log from DB and check whether if the callerID that was passed is existing

Code: Select all

($AcalleridCOUNT < 1)

In my case, sometimes, the system is not saving the callerID in vicidial_live_agents and thus not passing any callerID value to check for dead calls.

I am still going through the code for further investigation. I hope someone could somehow help me with the current problem.
I've been searching the whole forum but still couldn't find the right answer.

How are the calls getting to that in-group exactly?

Hi Matt, calls are coming in through PRI Line, in which I set in extensions.conf as 's'

Code: Select all

; PSTN serves 's'
exten => s,1,AGI(agi-DID_route.agi)
exten => s,n,Hangup()


Then I have my DID set as what my PRI Line number is.

All incoming calls are fine but my problem is just sometimes, the call seems to be set as "dead call".
As of my investigation, I am currently going through to vdc_db_query.php, looking on how the callerid was being set.

Am I missing something here? I have your manuals and read them all, but I just cant get it why this occurs. I haven't tried asking other ViciDial system users too if they've encountered the same one as mine tho.

At this point, we have only a few clients using PRIs, and even less running much inbound traffic on them. As such, I haven't heard of this issue before.

I would suggest looking at the Asterisk CLI output(perhaps from the screenlog.0 logfile), and you may possibly need to enable PRI debugging to catch the issue happening.

How frequently does this happen?

What is the average number of inbound calls you handle in a day?

What is the average length of an inbound call?

Thanks for your feedback, Matt.

I've been monitoring the logs lately, and every call from PRI really goes through the system.

Please see list below for calls which I indicated if whether the customer hanged up or the system.
** The image seems a bit huge, please try to open it in a different tab/window, it has logs on the right side (whether from PRI signal hangup or system)

Please see report below for average inbound calls from In-Group

Code: Select all

Time range: 2017-06-26 00:00:00 to 2017-06-26 23:59:59

---------- TOTALS
Total calls taken in to this In-Group:                 52
Average Call Length for all Calls:                    156 seconds
Answered Calls:                                        50  96%
Average queue time for Answered Calls:               6.12 seconds
Calls taken into the IVR for this In-Group:             0

---------- DROPS
Total DROP Calls:                                       0  0%               drop/answered: 0%
Average hold time for DROP Calls:                       0 seconds

---------- CUSTOM INDICATORS
GDE (Answered/Total calls taken in to this In-Group):   96%
ACR (Dropped/Answered):                                 0%
TMR1 (Answered within 1 seconds/Answered):              0%
TMR2 (Answered within 1 seconds/Answered):              0%

---------- QUEUE STATS
Total Calls That entered Queue:                        50  96%
Average QUEUE Length for queue calls:                6.12 seconds
Average QUEUE Length across all calls:               5.88 seconds

Your questions:
How frequently does this happen?
- In a day, around 5-10 calls are being considered as "hangup". I also posted in "General Discussion" about auto-hangup, it seems that it is from the code I added to automatically hangup the agent if he/she is in a "Dead Call".

What is the average number of inbound calls you handle in a day?
- Average is 50 calls per day.

What is the average length of an inbound call?
- Average Call Length for all Calls: 156 seconds


From my investigation:
- I was monitoring the table "vicidial_live_agents" in which the system puts a unique "callerId" to the column "callerid". Most of the time, the system do insert a unique value of "MmmddhhmmssLLLLLLLLL" (from the comment of vdc_db_query source).
I also added a log in conf_exten_check.php->'REFRESH'->"BEGIN DEAD logging section", I found out that it checks the "vicidial_auto_calls" table where callerid = currentCallerId in which currentCallerId is from "vicidial_live_agents.callerid".
The result from "vicidial_live_agents.callerid" is null and thus the condition ($AcalleridCOUNT < 1) will always be true from this mysql query = "SELECT count(*) from vicidial_auto_calls where callerid='$Acallerid';".

I am still tracing the code about where and when does the system inserts the data to "vicidial_live_agents" table. Maybe there's just a conflict between the timing of insertion and query.

How did I replicate the issue:
- In my local environment, I do have a cloud SIP account which takes inbound calls and does outbound calls from and to any physical phone device that has a number.
I called my local vicidial setup many times and the issue is intermittent. But I did get the cause on how the system says the calls is dead.

Please see results below:

Code: Select all

MariaDB [asterisk]> select * from vicidial_live_agents;
+---------------+----------+----------------+------------+--------------+--------+---------+-------------+----------+----------+---------+-----------+---------------------+---------------------+---------------------+------------------------------------+----------------+------------+----------+-----------------+-------------+-----------------+-----------------+----------------+---------------+-------------------+------------------+-----------------------+------------------------+-----------------------------+-----------------------+-------------------------------+-------------------------------+--------------+---------------------+-------------------+-------------------+---------------------+---------+--------------+---------------+-----------------------+---------------+-----------------------------------+---------------+-------------------+---------------+------------------------+--------------------------+----------------+--------------------+---------------------+------------+-----------------+
| live_agent_id | user     | server_ip      | conf_exten | extension    | status | lead_id | campaign_id | uniqueid | callerid | channel | random_id | last_call_time      | last_update_time    | last_call_finish    | closer_campaigns                   | call_server_ip | user_level | comments | campaign_weight | calls_today | external_hangup | external_status | external_pause | external_dial | external_ingroups | external_blended | external_igb_set_user | external_update_fields | external_update_fields_data | external_timer_action | external_timer_action_message | external_timer_action_seconds | agent_log_id | last_state_change   | agent_territories | outbound_autodial | manager_ingroup_set | ra_user | ra_extension | external_dtmf | external_transferconf | external_park | external_timer_action_destination | on_hook_agent | on_hook_ring_time | ring_callerid | last_inbound_call_time | last_inbound_call_finish | campaign_grade | external_recording | external_pause_code | pause_code | preview_lead_id |
+---------------+----------+----------------+------------+--------------+--------+---------+-------------+----------+----------+---------+-----------+---------------------+---------------------+---------------------+------------------------------------+----------------+------------+----------+-----------------+-------------+-----------------+-----------------+----------------+---------------+-------------------+------------------+-----------------------+------------------------+-----------------------------+-----------------------+-------------------------------+-------------------------------+--------------+---------------------+-------------------+-------------------+---------------------+---------+--------------+---------------+-----------------------+---------------+-----------------------------------+---------------+-------------------+---------------+------------------------+--------------------------+----------------+--------------------+---------------------+------------+-----------------+
|           632 | agentone | XXX.XXX.XXX.XX | 8600051    | SIP/agentone | INCALL |   60797 | ######      | 0        |          |         |  13390596 | 2017-06-29 09:45:58 | 2017-06-29 09:46:20 | 2017-06-29 09:45:53 |  AGENTDIRECT#################### - | XXX.XXX.XXX.XX |          1 | INBOUND  |               0 |         216 | 0               |                 |                |               | NULL              | 0                |                       | 0                      |                             |                       |                               |                            -1 |         1823 | 2017-06-29 09:45:58 | NULL              | Y                 | N                   |         |              |               |                       |               |                                   | N             |                60 |               | NULL                   | NULL                     |              1 |                    |                     |            |               0 |
+---------------+----------+----------------+------------+--------------+--------+---------+-------------+----------+----------+---------+-----------+---------------------+---------------------+---------------------+------------------------------------+----------------+------------+----------+-----------------+-------------+-----------------+-----------------+----------------+---------------+-------------------+------------------+-----------------------+------------------------+-----------------------------+-----------------------+-------------------------------+-------------------------------+--------------+---------------------+-------------------+-------------------+---------------------+---------+--------------+---------------+-----------------------+---------------+-----------------------------------+---------------+-------------------+---------------+------------------------+--------------------------+----------------+--------------------+---------------------+------------+-----------------+
1 row in set (0.00 sec)


MariaDB [asterisk]> select * from vicidial_auto_calls;
+--------------+----------------+---------------+--------+---------+----------------+----------------------+-----------------------+------------+--------------+---------------------+-----------+------------+---------------------+----------+----------------+------------+------------+----------------+-----------+----------------------+
| auto_call_id | server_ip      | campaign_id   | status | lead_id | uniqueid       | callerid             | channel               | phone_code | phone_number | call_time           | call_type | stage      | last_update_time    | alt_dial | queue_priority | agent_only | agent_grab | queue_position | extension | agent_grab_extension |
+--------------+----------------+---------------+--------+---------+----------------+----------------------+-----------------------+------------+--------------+---------------------+-----------+------------+---------------------+----------+----------------+------------+------------+----------------+-----------+----------------------+
|          216 | XXX.XXX.XXX.XX | ############# | CLOSER |   60797 | 1498697155.230 | Y6290945560000060797 | SIP/########-000000dc | ##         | ###########  | 2017-06-29 09:45:56 | IN        | CLOSER-1.5 | 2017-06-29 09:45:57 | NONE     |              0 |            | agentone   |              1 |           |                      |
+--------------+----------------+---------------+--------+---------+----------------+----------------------+-----------------------+------------+--------------+---------------------+-----------+------------+---------------------+----------+----------------+------------+------------+----------------+-----------+----------------------+
1 row in set (0.00 sec)


Prior:
$stmt="SELECT status,callerid,agent_log_id,campaign_id,lead_id from vicidial_live_agents where user='$user' and server_ip='$server_ip';";

### DEAD logging section
$stmt="SELECT count(*) from vicidial_auto_calls where callerid='$Acallerid';
$AcalleridCOUNT=$row[0];

if ( ($AcalleridCOUNT < 1) and (preg_match("/INCALL/i",$Astatus)) and (strlen($Aagent_log_id) > 0) ){
$DEADcustomer++;
...
}

echo <...>'|DEADcall: ' . $DEADcustomer<...>;

By the way, I am using "callinqueuegrab" function to grab inbound calls

We have made some changes in the code since the version you are using, so I would recommend upgrading to the most recent svn/trunk revision and see if that fixes this issue.

Thanks for the response, Matt.

I would like to upgrade my version to the latest one, but I just want to ask this new Log that was present in agi:

Code: Select all

DBI::db=HASH(0x16c8598)->disconnect invalidates 1 active statement handle (either destroy statement handles or call finish on them before disconnecting) at /usr/share/asterisk/agi-bin/agi-VDAD_ALL_inbound.agi line 3707, <STDIN> line 47.

I think this error caused the agi not to update the DB table/s.

Do you have recent changes in agi-VDAD_ALL_inbound.agi that might have resolved this issue?

Hi Matt,

I think I found the problem.

In vdc_db_query, inside ($ACTION == 'VDADready') condition, it has a query statement that resets "vicidial_live_agents" table:

Code: Select all

UPDATE vicidial_live_agents set uniqueid=0,callerid='',channel='', random_id='$random',comments='',last_state_change='$NOW_TIME' $vla_autodialSQL $vla_pausecodeSQL where user='$user' and server_ip='$server_ip';

And in agi-VDAD_ALL_inbound.agi, it has a query statement that sets "vicidial_live_agents" table:

Code: Select all

UPDATE vicidial_live_agents set status='QUEUE',lead_id='$insert_lead_id',uniqueid='$unique_id', channel='$channel', callerid='$callerid', call_server_ip='$VARserver_ip',comments='INBOUND',ring_callerid='' where user='$VDADuser';

These statements does execute at the same second, but I've figured out that sometimes, vdc_db_query comes in last.

Scenario:

Correct case:
1. Inbound call coming in
2. agi-VDAD_ALL_inbound.agi loops until an agent picks up the queued inbound call
3. When callsinqueue is grabbed, ($ACTION == 'VDADready') condition is executed first (includes reseting of "vicidial_live_agents" table)
4. agi-VDAD_ALL_inbound.agi inserts data to "vicidial_live_agents" table
5. agi-VDAD_ALL_inbound.agi then ends the script "AGI Script agi-VDAD_ALL_inbound.agi completed, returning 0"

I monitored the timing of data reset and insertion.
There are times that data insertion(from agi) comes in first then vdc_db_query resets that data.

Here is the time log upon inserting and reseting:

Insert Time: Thursday, June 29, 2017 15:09:32.391
Reset Time: Thursday, June 29, 2017 15:09:32.398193

See the difference in millis.

I don't know if this happens in other systems too, but it does occur in both production and local system as I'm working with.

I think that's one of the issues I fixed when I overhauled the related code in March. Give an upgrade a try and let us know if it works for you.