I think the answer is, in the rare circumstance that SIP / T.38 is working perfectly, you would not change. We have big customers doing tons of faxing and they desperately need this solution because they can't get SIP / T.38 to an acceptable failure rate.
If you have an ideal setup - modern fax machine, fiber internet, correctly configured ATA (which is, by far, the biggest problem we've had - people just won't read the guides thoroughly), your expected failure rate is about 8% on a T.38 ATA. For small offices who send/receive a fax once in a couple of months, this is a fine solution.
HTTPS ATAs only fail when the party on the other end of the fax fails; which makes them at least as reliable as traditional POTS lines. They are probably more reliable because we will retry the fax 9 times before failing it. So if you need near 100% reliability, you need to use the HTTPS ATAs.
The reason we are charging monthly for the ATAs is because that is how we are charged for them. We have to buy software for these things to work, and its expensive. Most of our competitors who offer HTTPS ATAs charge north of $15/mo.
@jasgot apparently Unifi uses STUN for some UDP traffic stuff in some cases. None of the normal stuff, must be log shipping which is a communications channel. They recommend having the port opened and forwarded. But it shouldn't cause problems. They noted that they only added the warning recently so it might have always had the issue without reporting it previously.
If by recently they mean 3 years ago, then I guess that was recent.. I've been having those errors for what seems like ages.
Correct, this has been there for ages now. STUN errors are common on Cloud Controllers which is all we have.
For just three? I might actually just suggest something more like 8x8 - Do you really need a full PBX for just three phone?
Yes, I do recognize that 8x8 costs more per user then a PBX hosted on say Vultr - ...
Not for 3 people it doesn’t. Unless you are set and forgetting it.
Last I heard - NTG did this at $12+/month per user, but at that few, it could be a lot more than that.
If your friend can manage it all themselves, they could get away with the PBX functions inside VOIP.ms - they've brodened their PBX offerings several times over the past year. i.e. expanded it's functionality.
Ability to have a large deployment with security built in already and not lose that.
Do you know if it is FIPS 140-2 certified?
Almost certainly not. That is a "pay the government for favours" cert that only big vendors can do. No small project can think about doing stuff like that because there's no way to make money from having done it and it doesn't just cost the developers an arm and a leg, but it directly takes away funding and development time from their actual users. So the developers don't wait to lose the money, and the real world customers don't want them focusing on something that's only for political reasons.
While I don't know 100% that either is certified, I'm certain that they are not and have no interest. It just doesn't make sense financially or ideologically.
While I think Scott's a bit overblown with the whole Windows Server and SQL server to be "serious" I see where he's coming from.
For example sticking with Windows 10 for example is likely fine because I'm assuming it's being run on and from a single machine connected to the gate system, not a remote server, etc...
It's a licensing requirement if you want security and reliable multi-user access. Otherwise you have to use the shared-file system of a JetDB that is completely exposed to things like ransomware. And that is highly flaky once you have more than about five users.
This really seems like a single computer setup - so while what you mention could be good, might be overkill for this setup.
It is a Raspberry Pi setup, IMO. I think @JasGot is right on that.
I think he is off on the "wishing he had 5 hours" thing though.
I don't know enough about controlling Pi pins to handle this. I think that would be better than the serial interface for the relay control. But it will also require then new wiring which is physical.
The barcode readers should be a standard listen for input handler.
The database design should be pretty straightforward.
The user interface does not sound like it needs to be complex, but like anything, you need to make it comfortably usable, or users will not use.
Finally, security of the application, it's users, data, etc will have to be designed.