So as someone who is trying to build a very simple non-commercial SIP VoIP PBX (10-20 extensions, no trunks, maybe voicemail and conferencing), I’m wondering a few things:
Does anyone use Asterisk in a purely stand-alone mode, with no database, web server, etc, to accomplish this?
Are there any references for the “absolute minimum viable Asterisk” configuration available?
Is Asterisk actually supported on non-Linux platforms (i.e. BSD, MacOS), or is it more of a “it might work, we don’t know” kind of thing?
Do people actually configure Asterisk by editing several dozen inter-dependent configuration files, or are there tools or configuration generators (aside from FreePBX or Incredible PBX) for this?
So as someone who is trying to build a very simple non-commercial SIP VoIP
PBX (10-20 extensions, no trunks, maybe voicemail and conferencing), I’m
wondering a few things:
Does anyone use Asterisk in a purely stand-alone mode, with no database,
web server, etc, to accomplish this?
Yes.
Are there any references for the “absolute minimum viable Asterisk”
configuration available?
Not that I am aware of. Others may know differently.
Is Asterisk actually supported on non-Linux platforms (i.e. BSD, MacOS),
or is it more of a “it might work, we don’t know” kind of thing?
Depends what you mean by “supported”. Certified versions of Asterisk with paid
support contracts are only available for Linux.
Community support such as this list/forum is available for anything you can
get it to run on, although if you run into problems during the build process,
you might not find many people who’ve tried building it on whatever you have
selected.
Do people actually configure Asterisk by editing several dozen inter-
dependent configuration files, or are there tools or configuration generators
(aside from FreePBX or Incredible PBX) for this?
Yes to the first part; I think not to the second (but again, others may know
differently).
Yes. I’d say most members of this forum do the same*. That’s why we refer posters to the FreePBX forum for any questions that smell like FPBX. Many solutions proposed here would be difficult to implement in FPBX.
Look at ./configs/basic-pbx/README included in the source distribution. It may yield some clues.
I have no experience outside of Linux. I’d suggest running Asterisk on a separate computer like a Raspberry Pi. People expect telephones to ‘always work’ and are not tolerant of outages for any reason.
My typical commercial production installations only uses about 10 configuration files** and only 4 have been touched this year. I’ve never used FreePBX or IncrediblePBX. I looked at the ‘rats nest’ of configuration files and bailed
*) Excluding commercial production systems.
**) In modules.conf I specify ‘autoload = no’ and specifically load the modules I use. “Parts left out don’t get broke”
For one project, back in the days of sip.conf, I used an m4 macro definition to generate entries for each extension according to a common template. This way, each new extension only needed one line to add. Then I would regenerate the actual configuration file from the template source file.
Nowadays, I think I would probably figure out a way to build the configuration from a database.
Although I recognize it might be old news here, I was greatly amused, in an ironic sort of way, by this paper that describes a semi-automated process for stripping an Asterisk configuration from dozens of files and tens of thousands of lines of configuration down to four files: A Minimal Working Configuration Set for Asterisk | Incite
That’s a PAX, not a PABX. If you don’t have provider connections, you are not a branch of the PSTN, which is what the B means. (A is automatic, although it tends to get dropped from PABX these days. The alternative is a PMBX, which I used once, but is now a museum piece.
What sometimes catches people out when going isolated is DNS. You still need a valid name resolution infrastructure.
For SIP, it may work on non-Linux Posix systems, but for analogue, or TDM sytems, the DAHDI channel driver is a, specifically, Linux driver.
Some proprietary codecs are only available for machines that have evolved from the Intel 32 architecture (which includes amd64, but not Intel’s original 64 bit architecture). In particular ARM is not supported for those codecs.
I half remember that some other code has conditional optimised code for the above Intel type machines.
That is fine historical perspective, thank you. It does seem as though in practice that version of the B is also on the way out…
For example, connecting SIP trunks to multiple different providers to obtain LCR and recognizing that not all of the providers offer A-Z routing to anywhere on the PSTN would not negate calling the box a PBX, even if you can only dial A-Y. So you could run a PBX on Mars without offering calls to Earth and still call it a PBX
Per a rusty old copy of Newton’s Telecom Dictionary, the B for branch means “it is a small phone company central office.” Which if you run a (great? terrible?) phone company that only connects your subscribers with each other eg. M$ Teams, you can proffer up this gem:
Microsoft provides complete Private Branch Exchange (PBX) capabilities for your organization through Microsoft Teams Phone. However, to enable users to make calls outside your organization, you need to connect Teams Phone to the Public Switched Telephone Network (PSTN).
…considering that is one version of what users read and understand when they look in to this kind of thing, here’s to hoping we all get along and agree with OP on the PBX part without peppering too much PAX (or UC!) talk in to the mix.
Back to OP…
Excellent scale for doing this by hand! Welcome!
Yes, but all the really fun stuff is in the “dialplan” – the extensions.conf and/or extensions.ael configuration files.
For the non-dialplan portions, there are some tools in Asterisk which can help, including res_phoneprov module for templating out per-phone configurations – so, phone boots up, asks Asterisk for configuration file based on MAC address via HTTP, and appropriate bits of PJSIP configuration for that phone are substituted into the phone’s (usually XML) config file.
There’s also abstraction options available in several files… a lot of the PJSIP configuration boilerplate can go into common profiles that you inherit in each extension, for example:
…then the bulk of your MACD takes place in those files, which you can version control with eg. git (this part is much harder with the GUI tools.)
Best advice: start slow, talk to your power users, get a couple of phones on your test bench, and keep your testing PBX for testing even after production is first achieved.
and agree with OP on the PBX part 
without peppering too much PAX (or UC!) talk in to the mix.