Queue CallBack not performing call backs

Hello,

We are currently using the VQ Plus 30 day trial and were trying to set up call backs. Currently when I test nothing shows up pending and we received no call backs. Scenario I’m using is I call from my desk phone and have the agent phone on the line with the, I then call in from my business cell (next in line), then my personal cell (second in line). Once i receive the message on my personal cell to press 1 for a call back I enter the information and then it hangs ups.

Afterwards if I check the call back report there are no pending call backs. If i hang up the original call and have the agent answer the next call on my business cell I still don’t receive a call back to my personal cell.

any thoughts?

Is the queucallback service running

From the CLI do a

/etc/init.d/queuecallback status

Yep that was it. I didn’t realize there was a service that needed to be running. Thank you.

One additional question in regards to this, when the call back went to connect to the agent in the queue the caller ID came up unknown. Is there a way for it to pull the caller ID of the customer who received the call back?

Hello,

I realize that this is an old thread, so perhaps I should open a new one. If that is the case, just let me know.

We have a system that has the queue callback module installed. This system is for a call center, a good amount of call volume. Initially, when we set the system up, the queue callbacks were working properly. However, there is now an issue where the callers are not being called back at all, even after a day or so. In the queue callback reports, under the “Failed callbacks” section, I can see numerous failed call backs, with the reason of “Maximum retries exceeded.” This makes sense.

In the “Successful callbacks” area, I can see that the system apparently calls back about 3-4 people per day, successfully. This is a low number of call backs, due to the high call volume of this system, and the pending callbacks that I will mention next.

In the “Pending callbacks” area, there are about 300 pending callbacks. Most of these pending callbacks are in the same exact queue position. The line items all have different call back numbers, however, most of them are in the same position. A couple of them are in position 2, a couple of them are in position 6, but most of them are in the same high position (2315).

For now, we have disabled the queue callback option on the queue, because we do not know how old these pending callbacks are.

Can anyone help diagnose this problem?

FreePBX version: 10.13.66-21

Thank you!

Have you tried to kill the call back service and restart it?

I have not. What would be the exact command to do so? service queuecallback stop/start?

Before I would try that, Is there a way to completely empty the pending callbacks? I do not want pending call backs from a week ago, going out today. Is there a way to clear them out?

kill this process:
/usr/bin/php –q /var/www/html/admin/modules/vqplus/queue-callback.php

run this to restart the process:
/var/www/html/admin/modules/vqplus/start-queuecallback.sh

Run this to verify the service is running:
/var/www/html/admin/modules/vqplus/check-queuecallback.sh

Thanks, I’ll give that a go. However, is there a way to clear out the pending callbacks before I would do this?

Also, I do not have the *.sh files in that directory. I have:

asset functions.inc i18n logs Monitoring page.queuecallbackreport.php sounds views
Console functions.inc.php install.php module.sig page.qrules.php page.vqueue.php uninstall.php Vqplus.class.php
etc hooks LICENSE module.xml page.queuecallback.php queue-callback.php utests

Perhaps we’re also working off different versions, I am the guy supporting the system James originally posted about so perhaps we either have an older version in place, or some customization in place for it.

we’re currently on 12.0.13.3 of vqplus

Ahh, that could be it.

It looks like it was renamed to just “Queues Pro.” We have 13.0.26.9. The description of the module is:

Description: (Formerly Virtual Queue Plus) MODULE REQUIRES A LICENSE FOR IT TO FUNCTION. Please visit www.schmoozecom.com/oss.php. Queue Pro adds additional advanced features to Queues module.

So I did some more digging, and here are some more findings:

The service is not running on the server (verified by running “service queuecallback service”)

However, if I look in the vqplus_callback_log in the mysql asterisk database, I can see that there were in fact a couple of successful calls each day. I see this by running this command:

select FROM_UNIXTIME(timestamp), queue_num, callback, success, reason from vqplus_callback_log order by timestamp desc limit 100;)

I also looked in the /var/log/asterisk/qcallback_out.log file and repeatedly see these errors:

`2017-09-01 10:19 -04:00: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column ‘cbid’ cannot be null in file /var/www/html/admin/modules/vqplus/functions.inc/ge$
Stack trace:

  1. PDOException->() /var/www/html/admin/modules/vqplus/functions.inc/geters_seters.php:215
  2. PDOStatement->execute() /var/www/html/admin/modules/vqplus/functions.inc/geters_seters.php:215
  3. vqplus_callback_log_add() /var/www/html/admin/modules/vqplus/functions.inc/callback-daemon.php:286
  4. vpos_callback_return() /var/www/html/admin/modules/vqplus/functions.inc/callback-daemon.php:163
  5. vpos_join() /var/www/html/admin/modules/vqplus/functions.inc/callback-daemon.php:75
  6. {closure}() /var/www/html/admin/libraries/php-asmanager.php:1486
  7. AGI_AsteriskManager->process_event() /var/www/html/admin/libraries/php-asmanager.php:336
  8. AGI_AsteriskManager->wait_response() /var/www/html/admin/libraries/php-asmanager.php:239
  9. AGI_AsteriskManager->send_request() /var/www/html/admin/libraries/php-asmanager.php:887
  10. AGI_AsteriskManager->GetVar() /var/www/html/admin/modules/vqplus/functions.inc/callback-daemon.php:147
  11. vpos_join() /var/www/html/admin/modules/vqplus/functions.inc/callback-daemon.php:75
  12. {closure}() /var/www/html/admin/libraries/php-asmanager.php:1486
  13. AGI_AsteriskManager->process_event() /var/www/html/admin/libraries/php-asmanager.php:336
  14. AGI_AsteriskManager->wait_response() /var/www/html/admin/modules/vqplus/functions.inc/callback-daemon.php:93
  15. include() /var/www/html/admin/modules/vqplus/queue-callback.php:24`

I don’t know if this is related or not, but there are a ton of errors in this file, and thought this may be related.

Is anyone else having this issue?

On FreePBX I was never able to find a permanent solution for this issue outside of stopping/starting the service to kick it back in.

As the other member, Ben, replying to you stated i left the company that this system was at and went to another. The system i support now is built on a fully custom asterisk set up. Here I built my own custom queue callback dialplan with sql inserts which then uses a php script to check the database and create the call file. so far I’ve had no failures in callbacks and even have it with the ability to check if the call came from inside (this helps keep us from using channels on the pri when no necessary).

But if i had to wager a guess, it’s an error getting the info in your DB because of cbid being NULL based on your last post. If there is not cbid (assuming that is callback ID, on mine i have it made as callback_id) then there cannot be a callback. So again another guess here but I would think it would be when the system goes to store the information from the callback it is not properly writing the cbid to the table in the DB.

Not sure if this will help you along but it’s a thought. Maybe perform a test call while turning up your verbose on the CLI in asterisk to see if you can see it writing to the DB.

Thank you for getting back to me on this! Is it safe to remove the pending callbacks from the database and restart the service?

Don’t see why you couldn’t manually remove the pending callbacks. I would say take down the info for the call backs and that way if they do actually need callbacks you can send the info to the group responsible for the calls.

Right. Will do. I think I will probably have to get paid support on this, because this seems like a bug in the software/module.

Likely the best course of action. Also would open a bug report on https://issues.freepbx.org/

1 Like

No that is incorrect.

Commercial module support is

FREEEEEEEEEEEEEEEEE.

I was just told by a Sangoma sales rep that I have to pay for support on this… Now I’m really confused.