For most dell systems, idrac, bios, CPLD, raid controller, nics, all have firmware updates that should be applied. Power supply sometimes, not usually necessary.
But R720, don't do it. T620 don't do it. R620, don't do it.
I haven't had any issues before or after that cursed xx20 generation.
DONT DO IT!
Most r720's have a bad flash chip so the idrac update will fail, and you'll have 100% fan speed and a nice idrac init failure that requires keyboard intervention at every boot up. Mobo replacement is the only fix once your there.
Skip bios, and idrac updates at all cost!
Raid controller and NICs can be safely updated though.
T620 - died during idrac update. R720 - died during idrac update. Customer R720 - died during idrac update.
A few times it happened under warranty and the mobo was swapped out, but r720 is no longer warranty eligible. Not worth the risk, basically 0 benefit too if the system is working today.
I ran FreeSwitch with a signalwire sip trunk. I don't think there's much cheaper than that. Pay as you go, less than a penny per minute. Only monthly fee is holding onto the numbers you want, each number is like $0.50 per month.
But installing and maintaining it is a challenge for even good sysadmins.
I'd go with 3CX or a similar all in one provider if I had to make the call.
Also, use a good USB headset and a soft phone on your computer instead of that old cisco handset. Get away from handsets ASAP. They are the most expensive thing, vendor support dries up fast, and the audio codecs go stale. Firmware vulnerabilities emerge, compliance requires you to update them, so every 5 years, new handsets for everyone. It's a joke. USB headset or a good USB speaker phone will work with any system, until they physically break. 3cx has soft phone clients so handset isn't needed at all.
Sccm is too big. I don't think you'll find an all in one alternative.
Piecemeal is easy though. Wazuh for inventory. Chef or ansible for packages and desired state config.
Lots of pxe boot deployment options, including wds, which sccm pxe is built on.
Maybe tackle one feature at a time and pose your questions one at a time, so people doing pxe boot imaging can chime in on that specifically for example.
Ah, love it!
Then yes I bet some great options exist then on windows and Linux. Old windows 2000's included "net meeting" did exactly this. Type an ip address, click "call" and it would ring the other person's computer on the LAN if they had net meeting open. Even had a cool ms paint based shared whiteboard, an app way ahead of its time.
Now you got me curious! In this modern world that problem "no longer needs solving" as the expectation has moved on to mobile device, and works over the internet. Fun to go back a little bit and make something basic and resilient again!
Hope you find something that works, worst case a basic app like net meeting could probly be replicated without too much coding. All the features the app would need have libraries for functionality in most programming languages at this point.
All devices like android and ios are 100% firewalled, blocking ALL incoming, unsolicited traffic. No way around this without rooting.
So no, it's not possible as you've described where it is strictly peer to peer with no server involved.
But there is some hope. Apps like Nextcloud Talk use a server, but are 100% open source, free, and hostable on a LAN. And matches what you're after feature-wise.
You encapsulate the awesomeness of the open source community with this content. Thanks for sharing!
Your describing port knocking.
An interesting and (effective?) security by obscurity technique.
An example:
Host port 443 web server, but by default the port is fully firewalled unless you give the secret "knock".
So you hit port 5444 first, the router sees a request to 5444, and adds the source address to a list of allowed devices for the actual 433 port. Now, just your client ip can successfully connect to port 443 as normal.
Most security researchers balk at it as wholly dumb and ineffective. But I disagree. With port knocking I get ZERO hits to my publicly exposed SSH port 22 on my actual server. The firewall shows all the port scanners hitting my block port 22, thousands per day. But unless they hit my secret combo of ports first, they don't get to the allow port 22 rule.
More complex rule would be used in production:
Hit port 5001, then 5009, then 6120, then 4001 now you can hit your actual service port. And if you don't hit them in order, no go. To reach 5009, you must hit 5001 first, to hit 6120, you must have hit 5009, which already required to have hit 5001. Add a rule where if you hit 5008, it all closes and starts over to preclude a port scanner from triggering all your rules.
Mikrotik routers have the ability to do this with firewall rules that just trigger and add a client ip to a transient src-address list. The longer your chain the better.
Android has an app called "port knocker" that makes it easy to open the door any time automatically.
Only issue is someone watching your traffic will easily see your port knocks, but that's a local, persistent adversary, not a transient scan, so yea, I get why serious security people say meh, but the threat your preventing as an individual is the random drive by scans and brute force scripts, and it's 100% effective at preventing those.