Hi @superdigi,
The issue is not with your ASTPP solution, that seems to be working fine, the call is passing through and the responses on both systems are what I would expect.
Where I see the problem is when the call is answered and passed to extension 8368 (this is the routing extension for outbound campaigns without AMD activated).
The AGI script is fired to find an agent to take the call based on your campaign settings but whatever happens during that process returns no results so then the dialplan moves on to priority 5 of the 8368 dialplan extension which is Hangup
To find out more, I would need to see the AGI log. It may be you don’t have it switched on, in which case you’ll need to activate it in the server entry on your setup. AGI Out must be “File” or “Both”.
The file will likely be in /var/log/astguiclient if GoAutoDial haven’t changed the default location of the vicidial agi scripts logs.
It will take up to a few minutes for the setting to become active after making the change if your AGI Out was STDERR before.
Just a stab in the dark though, if this instance of GoAutoDial has ever been abruptly restarted, I.E power loss, hard reset etc, then I would recommend you run the following on the command line of the server with the database on it:
mysqlcheck --auto-repair
If you have a password on your root account from localhost then you’ll need to do:
mysqlcheck -p --auto-repair
then enter your root password followed by enter to achieve the same.
One common cause of the issue your facing is crashed database tables following an abrupt restart or shutdown without issuing the shutdown command on the CentOS console/command line.
If that doesn’t work, grab the VDAD_ALL_outbound log after trying a call again so I can see what’s happening during the execution that’s causing no results (agents) to be returned to send the call to.
