Agent Phone not ringing on Login to Dialer server

[edooze]

Hi all,

I'm running a vicibox-express install with an additional Web/Dialer server added via the vicibox iso.
Both have been updated via SVN (versions in sig)
I'm running virtualised (adds +3 to 'Holy Internet Flame' when cast on the player) - but I've only got a small setup at the moment. 2 agents on the express server, and 1 to be set up on the new server.

I'm having trouble getting the additional dialer server to call the agent when they log in.

I have managed to connect the servers via the cluster setup, and all seems to be fine there. The server is created in Admin - Servers.
The agent can register their phone, the asterisk CLI reports it as registered.
The agent can dial the echo test successfully, and can dial extensions on the express server.
The agent can dial out from the softphone directly, and the CLI reports a call is being made.

When I log in on the new server, vicidial will let me log in fine, but won't call my phone so I can answer it. It doesn't say there is no agent available after a period of time, either.
The express server is working fine, we can log in and call on it etc.

The additional server is a new setup today. This setup has worked fine for me in the past, but I've not struggled to get the phone calling before as far as I can remember.

Many (apparently deprecated) posts online tell me to check the scratch install doc, which directs me to check the manager.conf and astguiclient.conf entries, but they all appear to be working correctly.
The server and phone IPs appear to be the same in the settings.

I'm sure I'm forgetting some things, but what else can I check?
Any help appreciated.

[edooze]

I've created a new carrier on the web interface of the new server, and it populates correctly on the master server. There doesn't seem to be an issue with sync.

I have noticed that the server is in red on the summary page. It is in a different timezone and has been set up as such, so I assume this is because the times don't match across both. Load on the new server is practically nil as it's just been built.

The output of screen -ls on the new server is as follows:

There are screens on:
1338.ASTfastlog (Detached)
1335.ASTVDremote (Detached)
1332.ASTVDauto (Detached)
1329.ASTlisten (Detached)
1326.ASTsend (Detached)
1323.ASTupdate (Detached)
1118.asterisk (Detached)
1111.astshell20190409161130 (Detached)
8 Sockets in /var/run/screens/S-root.


On the old server: screen -ls
There are screens on:
1646.ASTVDremote (Detached)
1643.ASTVDauto (Detached)
1640.ASTlisten (Detached)
1637.ASTsend (Detached)
1634.ASTupdate (Detached)
1437.ASTemail (Detached)
1434.ASTVDadFILL (Detached)
1431.ASTfastlog (Detached)
1428.ASTVDadapt (Detached)
1396.asterisk (Detached)
1326.astshell20190409180959 (Detached)
11 Sockets in /var/run/screens/S-root.

I assume this is intentional due to the reduced tasks for the web/dialer server.


The next step is to rebuild the infrastructure again from the ISO and attempt to restore the backup (from the script) on top of the new cluster. I'd rather not have to if I can avoid it, so any suggestions would be appreciated.

[williamconley]

is the phone an "on-hook" phone? If so, it's not supposed to ring until the agent gets a call (this setting should only be used for inbound and transfer calls, of course).

the time zone of the server is not relevant, BUT all servers must be physically in the same location, preferably with a gigabit switch connecting them. Vicidial deal with nanosecond timing, which fails miserably when servers have to transmit DB queries over the internet.

also: set all servers to the same time zone. if your room is in a time zone different than other rooms,there is a setting under admin->servers for each server to allow you to set the time zone for that server to display on web AND each phone also has a time zone to specify the zone to display to the agents.

good job posting your specs EXCEPT: Vicibox has three significant digits. It's not "8.1" but "8.1.?". It makes a difference in many cases.

Do Not use Express install. Use expert mode. Express install is pretty much for those who have no idea what they are doing and are in need of hand-holding. It's also not maintained to the same level as the Expert/Advanced mode installer.

Do Not attempt to use Virtualized Vicidial in production for more than one or two agents. It will fail. You've been warned. If you're curious as to why, google is your friend. There's been a lot of discussion on the topic. Do not tilt at this windmill until you're already making money with Vicidial.

Do not answer your own posts. If nobody has answered yet, edit your post instead. Your post disappears from the Unanswered list when YOU answer your own post with a second post. Instead of putting yourself higher in the list ... you are removed from the list. This can (and often does) result in significant time before your first answer.

[edooze]

Thanks for the follow-up. A few good things to try.
The phones are not 'on-hook', as this is an outbound campaign. I'll change the timezones for the servers themselves and see how that changes things with the reports etc.

So, the servers are physically in different locations and connected via a VPN. I know, I know, virtualised and a VPN connection is asking for trouble. We get database sync issues, lead loading issues, and ERI statuses on more than a few calls. For the purposes of these campaigns it's not a dealbreaker, but we're definitely aware of the trouble we're causing ourselves with this kind of setup.

That being said, this is the first time that the phones have failed to ring on login. This setup has been in place since 2014 with only the issues mentioned above so I know it does work - it's just not working right now.

I think the exact issue might be too obscure to track down. I will attempt a rebuild with an entirely new cluster over the weekend and go 'round again. I'll keep this post updated with relevant info if I manage to track it down in future.

On a side note, really appreciate your work, Mr Conley. Many of the posts I reference have you to thank for any kind of useful information, so if it doesn't get said enough your input is hugely appreciated.

EDIT: So once I have received the error about time sync. I have updated the timezone on both servers to make them the same, and set the timezone in server settings to be the same as well. The CLI reflects the same time in messages, but unfortunately the issue still persists.

[williamconley]

We get database sync issues, lead loading issues, and ERI statuses on more than a few calls.

You left off "and phones not ringing". Because that's likely the reason. You can check the vicidial manager table (in mysql) and try to trace the command/request from issuance to completion and see why it fails. But you'll likely find that it's just going to be unreliable until you unvirtualize and/or put the servers in the same location.

FYI: There is zero advantage to having a server at the same location as the agents. There's plenty of disadvantage to have clustered servers NOT near each other. And virtualization problems are entirely "load" based. Low load, no big deal, but it will overload when using only a small percentage of the hardware's potential were it NOT virtualized (which is still handy if you have a bunch of 2-3 user systems).

But when you have a bunch of tiny systems, there's no need for clustering! lol.

Stages:

1) Agent login creates a manager table entry. visible in mysql table "vicidial manager".

2) script running in a Screen on agent-registration-dialer catches this entry and dials the agent, making several changes to the manager table entry along with way and requesting asterisk to make the call. logs in /var/log/astguiclient (if logging is on in admin->servers)

3) asterisk makes the call ... logs in /var/log/asterisk and on asterisk cli

[drodecker]

I'm stuck on this issue as well. Systems were running fine until promptly half way through the day today. We don't believe any admin activities were performed.

Have affirmed that the cluster of servers are all in NTP sync; they are all virtual on the same host.

In following Williams steps above, trying to evaluate Step 2 as Agents are not getting the phone call while On Hook.

Code: Select all

> asterisk -V
Asterisk 13.38.2-vici


And in Admin=>Servers, is Asterisk Version: 13.38.2-vici

In /etc/astguiclient.conf, the value of VARasterisk_version was merely 13, we've modified it-

Code: Select all

VARasterisk_version => 13.X

Upon login, a record is added to vicidial_manager:

Code: Select all

select * from vicidial_manager order by entry_date desc limit 2;
| man_id  | uniqueid | entry_date          | status | response | server_ip     | channel | action    | callerid             | cmd_line_b       | cmd_line_c       | cmd_line_d     | cmd_line_e  | cmd_line_f                                            | cmd_line_g | cmd_line_h | cmd_line_i | cmd_line_j | cmd_line_k |
+---------+----------+---------------------+--------+----------+---------------+---------+-----------+----------------------+------------------+------------------+----------------+-------------+-------------------------------------------------------+------------+------------+------------+------------+------------+
| 9550323 |          | 2021-10-18 16:04:34 | NEW    | N        | 172.83.90.124 |         | Originate | ACagcW16345981673103 | Channel: SIP/310 | Context: default | Exten: 8600054 | Priority: 1 | Callerid: "ACagcW1634598167310310310310" <8776356225> | Variable:  |            |            |            |            |


Bottom line, the agent is not getting called and is still receiving the generic error message:

There is a time synchronization problem with your system, please tell your system administrator

FYI-
VERSION: 2.14-830a
BUILD: 210920-2159

[drodecker]

Not clear how this is related, but the perl scripts connecting through AMI seem to get stuck telnet connecting to AMI:

Code: Select all

$tn->waitfor('/[0123]\n$/');

This seems to be a regular expression, however [0123] would fail (to find 0, 1, 2, or 3) given that the AMI shows 6:

Code: Select all

# telnet localhost 5038
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Asterisk Call Manager/2.10.6

Is the AMI version to be set somewhere?

[drodecker]

Resolved my problem-

I diagnosed that the dialer wasn't hitting the database, even after a fresh reboot.
I manually ran ADMIN_keepalive_ALL.pl, and that woke it up...

Diagnoses- crontab had it's first couple lines removed. Unknown why/how this occurred on MULTIPLE servers; but what is odd is that crontab was modified a couple days back; curious why the server wouldn't have died earlier.

Anyway; resolution was to re-add this to crontab:

Code: Select all

* * * * * /usr/share/astguiclient/ADMIN_keepalive_ALL.pl

[tardisdialer]

drokecker- thanks! that fixed it . The only thing I can think of , being absolutely clueless, is that the I ran the ssl setup within either vicibox-express or vicibox-install which asked about updating the crontab to renew the ssl cert every week (?). Anyway thank again totally saved me.