I have been thinking about whether Node Red could be used to configure an Asterisk server. Asterisk is a mature and fully-featured PBX software that's open source. However, configuring it is notoriously complicated and tedious - and the main GUI to do so has its own issues (including being complicated and tedious itself - sorry to anyone involved!).
Having previously used Twilio Studio I am aware that there are dramatically better interfaces for those looking to design (potentially complex) telephony and messaging systems. Designing in Twilio Studio and Node Red have some commonalities (and differences that I will come to). I am a huge fan of Node Red of course! This led me to wonder if Node Red could be used in this way.
Potentially this would provide a very sophisticated way to build VoIP (and other systems) - all on FOSS and free in other ways. A system could potentially run reliably on very simple hardware, and the ability to extend with Node Red in other ways would be incredibly powerful. Conversely, this could be developed to enable Node Red flows to access powerful telephony features.
There is however a substantial conceptual issue, which is what I am interested in comments on.
It would be brilliant to be able to configure Asterisk by creating and connecting nodes. For example, an endpoint node, inbound / outbound SIP trunk, IVR and so on. However, in Node Red this is of course not the purpose of connecting nodes. In this case, connecting these nodes to other specific types of node would ideally trigger a configuration change rather than passing data from one node to the next (etc.). Deploying the flow would implement that configuration, and allow status / monitoring info about the Asterisk server to be presented back and used as normal.
I wondered if anyone had addressed a similar issue in another setting (hard to search that up) or had any ideas about how this application could be constructively tackled in Node Red.
I think that there may be a couple of possible approaches.
The first is the one taken by UIBUILDER for its no-code nodes. In these, you pass in some data in a simple format and the node converts that to the required configuration output. But, that output is still just JSON data and so it can be further sent through additional no-code nodes building up something more complex before it is finally send to a master uibuilder node that sends it on to connected front-ends where it is finally converted into full HTML (actually you can do this part without a uibuilder node by sending to a uib-html node which converts the JSON to HTML in Node-RED).
So you could do something similar, having specific nodes that take an input and output a segment of configuration - perhaps in a more complex schema or maybe in the output format directly usable in Asterisk. But the point being that, because each node produces its own unique segment of the configuration, you can simply chain them together to get a final output.
The other approach would be for each node to write directly to the Asterisk config file(s) and merely output a simple trigger message to allow nodes to be chained. This might be much simpler but relies on having access to the filing system from Node-RED and having access to a location useful to your Asterisk server.
The first approach is likely to be more flexible overall but it also more complex. Potentially, it would allow you to do things like transfer the final config via email, MQTT, or some other comms method.
Actually, thinking about it, even the 2nd method would allow other forms of transfer since Node-RED can simply read the final file(s) back in and transfer them onwards. Still needs the filing system though. Whether that is a limitation would depend on where your Node-RED server is running.
That point was the missing link for me. Chaining the nodes together and passing the config means the downstream nodes can know what they're connected to and modify the config accordingly.
Asterisk has a few methods of changing config - including some older style APIs, a REST interface, a CLI, and of course editing the files and re-loading the server. Some of it is even uses JSON, which is convenient! I'm still working through what's possible there, but it might be straightforward to keep it quite high level in Node Red - i.e. avoid file manipulation.
I'm going to try and hack about with this and see if I can do a proof-of-concept - configure extensions, a SIP channel and dialplan. My conceptual/design abilities far outpace my actual coding/packaging abilities - much of what I need to do that I know nothing about is newbie stuff. Fun to learn though...
No problem, obviously it gets even easier if you can use a REST API since Node-RED is already good at that stuff.
But yes, Node-RED is great for chaining actions together and you don't HAVE to use the msg to pass data if all you want to do is pass along effectively an event.
BTW, did you check in the flows site to see if anyone has previously released an Asterisk node?
Good point. I had done an initial pass on other nodes, and node-red-asterisk-ami-manager is a very useful building block - although I hadn't realised how useful when I first looked. When I glanced before I thought from the description that it only monitors the status, but it does also allow you to issue commands. It makes use of the NPM asterisk-manager, and that looks like it does the heavy lifting of connecting to the AMI interface on Asterisk.
I have not used Asterisk for a long time now - but there is absolutely no reason you could not build a series of flows to build your asterisk configuration.
In the first instance (because thats all there was when i was doing Asterisk) i would look at generating the config files using Node Red - as it would be easier to audit and follow the decision path.
Longer term you could move this into the REST/AMI interrface
Each of the building blocks of an Asterisk config lends itself nicely to NR and using subflows that you can pass parameters to - such as a Trunk Subflow - that requires input to name the trunk and nominate the hardware etc for it.
Thanks Craig. I've had a bit more of a play, and the existing connectivity into the AMI interface works well so far. I can read and change config files, and lots more. Because of the way the AMI interface interacts with the config files it might easier to do it that way immediately - I will continue to have a play and see if that's the case.
