Page 1 of 1

Inbound Callback Queue ORPHAN Concern

PostPosted: Thu Nov 30, 2023 11:37 am
by jessiekidfernando
Hello Everyone,

Just want to know your thoughts on why we are seeing ORPHAN. Can confirm that it is being dialed though. Kinda weird because why we are seeing ORPHAN in the first place. Just worried since it affects our reporting. Any idea or reason why? I checked that the ORPHAN is being set by this script AST_VDadapt.pl whenever it is considered as stuck from SENDING status. Also do we have a reporting tool that could check the Inbound Callback stats? Thank you so much in advance.


MariaDB [asterisk]> select * from vicidial_inbound_callback_queue where icbq_status='ORPHAN' limit 5;
+---------+---------------------+-------------+-------------------+-----------------+---------------------+---------+----------+----------------+---------------------+----------------+---------------------+
| icbq_id | icbq_date | icbq_status | icbq_phone_number | icbq_phone_code | icbq_nextday_choice | lead_id | group_id | queue_priority | call_date | gmt_offset_now | modify_date |
+---------+---------------------+-------------+-------------------+-----------------+---------------------+---------+----------+----------------+---------------------+----------------+---------------------+
| 1296 | 2023-11-30 09:26:43 | ORPHAN | XXXXXXXXXX | 1 | U | 1452040 | CS | 99 | 2023-11-30 09:25:21 | -5.00 | 2023-11-30 09:32:00 |
| 1301 | 2023-11-30 09:42:00 | ORPHAN | XXXXXXXXXX | 1 | U | 1568667 | CS | 99 | 2023-11-30 09:41:16 | -5.00 | 2023-11-30 09:54:41 |
| 1307 | 2023-11-30 09:45:44 | ORPHAN | XXXXXXXXXX | 1 | U | 1478153 | CS | 99 | 2023-11-30 09:45:05 | -5.00 | 2023-11-30 10:00:34 |


MariaDB [asterisk]> select * from vicidial_dial_log where lead_id=1452040 limit 1;
+----------------------+---------+---------------+---------------------+---------------------------------------------------------------------+---------------------------------------------+---------+---------+-------------------------------------+------------------+-------------------+----------+
| caller_code | lead_id | server_ip | call_date | extension | channel | context | timeout | outbound_cid | sip_hangup_cause | sip_hangup_reason | uniqueid |
+----------------------+---------+---------------+---------------------+---------------------------------------------------------------------+---------------------------------------------+---------+---------+-------------------------------------+------------------+-------------------+----------+
| Y1300931450001452040 | 1452040 | 172.24.16.129 | 2023-11-30 09:31:45 | 8305888888888888090009*XX**1452040**4439096784*5588*5588**1*8600053 | Local/8305888888888888XXXXXXXXXXX@default | default | 90000 | "Y1300931450001452040" <XXXXXXXXXXX> | 0 | | |
+----------------------+---------+---------------+---------------------+---------------------------------------------------------------------+---------------------------------------------+---------+---------+-------------------------------------+------------------+-------------------+----------+
1 row in set (0.00 sec)

MariaDB [asterisk]> select * from vicidial_dial_log where lead_id=1568667 limit 1;
+----------------------+---------+---------------+---------------------+---------------------------------------------------------------------+---------------------------------------------+---------+---------+-------------------------------------+------------------+-------------------+----------+
| caller_code | lead_id | server_ip | call_date | extension | channel | context | timeout | outbound_cid | sip_hangup_cause | sip_hangup_reason | uniqueid |
+----------------------+---------+---------------+---------------------+---------------------------------------------------------------------+---------------------------------------------+---------+---------+-------------------------------------+------------------+-------------------+----------+
| Y1300954290001568667 | 1568667 | 172.24.16.129 | 2023-11-30 09:54:29 | 8305888888888888090009*XX**1568667**2013646616*5588*5588**1*8600053 | Local/8305888888888888XXXXXXXXXX@default | default | 90000 | "Y1300954290001568667" <XXXXXXXXXXX> | 0 | | |
+----------------------+---------+---------------+---------------------+---------------------------------------------------------------------+---------------------------------------------+---------+---------+-------------------------------------+------------------+-------------------+----------+
1 row in set (0.00 sec)

MariaDB [asterisk]> select * from vicidial_dial_log where lead_id=1478153 limit 1;
+----------------------+---------+---------------+---------------------+---------------------------------------------------------------------+---------------------------------------------+---------+---------+-------------------------------------+------------------+-------------------+----------+
| caller_code | lead_id | server_ip | call_date | extension | channel | context | timeout | outbound_cid | sip_hangup_cause | sip_hangup_reason | uniqueid |
+----------------------+---------+---------------+---------------------+---------------------------------------------------------------------+---------------------------------------------+---------+---------+-------------------------------------+------------------+-------------------+----------+
| Y1301000160001478153 | 1478153 | 172.24.16.129 | 2023-11-30 10:00:16 | 8305888888888888090009*XX**1478153**XXXXXXXXXX*5596*5596**1*8600052 | Local/8305888888888888XXXXXXXXXX@default | default | 90000 | "Y1301000160001478153" <XXXXXXXXXXX> | 0 | | |
+----------------------+---------+---------------+---------------------+---------------------------------------------------------------------+---------------------------------------------+---------+---------+-------------------------------------+------------------+-------------------+----------+
1 row in set (0.00 sec)

Re: Inbound Callback Queue ORPHAN Concern

PostPosted: Tue Feb 20, 2024 8:42 am
by mflorell
I haven't done much work on Inbound Callback Queue since I added it 6 years ago, although we have made several bug fixes since 2019, which is the age of the code your signature says your're running, so I would suggest upgrading to the latest svn/trunk revision of the code and see if the issue is still happening.

As for your specific issue, do you have a reliable method for replicating it?