VOIP Tools / On Call Manager

[bnichols_]

Hi Everyone,

Has anyone actually implemented VOIPTools with 3CX? Specifically the on call manager - we have a client with specific on call needs that change weekly (daily over holiday periods).

I’ve tried getting hold of their sales team but seem to be getting no where. Keen to know any active users and how easy the GUI is for on call scheduling.

Thanks!

 

[SweetAction]

We have, many of their tools. UI works, fairly easy to use, but I will say their support department is not something I want to work with. Good news is that most of their tools log very well and you can read/fix many issues yourself.

@VoIPTools Matthew, tagging you here.

 

[VoIPTools]

Somehow I had no idea this forum existed until today!

Regarding 3CX On Call Manager, you can take a look at this video. I just took a look at the video and was a little horrified by the lack of editing (excerpt of a webinar), but if you skip forward a bit, you can get to the useful content.

Regarding @SweetAction and the concern about our support team, I understand completely. We have support staff both in the USA and India. Some people struggle with the Indian accent, and we are always working to improve our support engineers' skills, but keep in mind that you can always contact us during USA work hours and ask to speak with an American.

In case you are wondering, our staff in India are our direct employees. 20+ years ago we flew to India, acquired a building, and hired our own staff. This is not outsourced support. Further, all of our engineers are required to pass the 3CX certification exams. In spite of being an American based company (Senior engineers are all based in the USA), we now have two offices in India -- Hyderabad and Deli.

Naturally, as the business owner, I'm always interested in receiving feedback from our customers and partners around the world. If you do not get the help you need from our support team, you can always poke me! If you want a web demo, we can coordinate that for you too.

 

[SweetAction]

Naturally, as the business owner, I'm always interested in receiving feedback from our customers and partners around the world.

In that case, my other piece of feedback is around security/best practices of installs/support.

To be clear, it's 100% possible to install everything in a secure/best practices manner, it's just not what is done by default.
Some example:

1. JWT token is stored in drivers/etc/hosts/voiptools/ and not something that should be done. Program files should be stored in program files, like program files\voiptools\common\ in this case. Using NTFS ACLs to restrict as needed. Configuration data in programdata (as is already done). And so on.
2. Support LOVES to flip ACLs to USERS FULL CONTROL on every folder used by VT. It doesn't need to be done, but it's like troubleshooting step #1 apparently. This is bad for many reasons. I'm surprise they don't go disabling UAC as the second step.
3. Every service installs using a local account to run the service. A local admin that it creates with a super short easy to see password. It should use a service account (a group managed service account, aka a gMSA) instead, for many reasons.
4. Everything wants to use SA for SQL access. Again, use a service account (the same gMSA mentioned above) that is NOT a sysadmin in SQL (dbo on the specific DB is fine).

So yes, I can go in after the installer is done and make changes. Revoke Sysadmin in SQL. Change the service account on the services. Fix the ACLs on the folders. and so on. But I shouldn't have to and it makes it a pain, especially during upgrades.

Look, I get it - you are writing software and installs for the lowest common denominator. Maybe the client doesn't have a domain or has really bad ACLs on their machines or other uncontrollable setups. How do you account for that, what load do you want to put on support, etc. Still, we all have a responsibility to push security forward and in 2024, this is really a bare minimum.