Hi everyone,
I am looking to integrate my FreePBX system with ERPNext and wanted to get the community’s advice on the best architecture to achieve this. My primary goals are:
Click-to-Call: Enabling users to initiate calls directly from within the ERPNext interface.
Contact/Data Sync: Syncing contacts or identifying callers when an inbound call hits the PBX.
Sangoma has the official CRM Link Commercial module that supports web hooks and Zapier.
I originally posted this solution, but it was rightfully flagged by the community for severe security and operational optics. I am rewriting this to provide the proper context and a strict caveat.
The Outbound Setup (Click-to-Call): I’ve been testing this script for the ERPNext to FreePBX workflow: GitHub - Nonikoff/Click2Call-for-FreePBX: Lightweight Click-to-Call API for FreePBX/Asterisk. Instantly connect extensions to outbound numbers from CRMs, web apps, and custom integrations. · GitHub It accepts a web request from ERPNext, rings your extension, and once you pick up, dials out to the contact.
The Security Caveat (Read Before Installing): As developers here correctly pointed out, this repo requires you to install two compiled, closed-source binaries. It has no registered domain, lists an anonymous email, and uses a Telegram bot for licensing. From a sysadmin perspective, dropping this blindly onto a production server is a massive security red flag.
To clarify what these binaries actually do under the hood, I deployed them in an isolated environment and monitored the network traffic. They execute exactly two outbound connections:
A request to resolve the server’s IP address.
A handshake with the licensing server.
There is no other outbound traffic or unexpected routing. However, day-one traffic monitoring is not a substitute for open-source trust. If you are going to use this, treat it as a proof-of-concept, sandbox it, or ensure you have strict outbound firewall rules in place. Do not install it on production blindly.
The Inbound Setup (Safe & Native): For syncing or pulling caller ID from ERPNext, you don’t need any third-party binaries. Your best bet is using the built-in CID Superfecta module in FreePBX. You can set up a webhook in Superfecta to hit the ERPNext API, grab the contact name based on the incoming number, and push it straight to your phone’s screen. It is entirely native, open, and avoids these security issues completely.
Asking a lot to have folks install 2 compiled binaries on to their servers with no insight as to what they do and without any real community reputation. The license has a sketchy email in it. All around probably not a great approach.
Edit: This comment makes no sense with the prior comment flagged off. Essentially the flagged comment had a repo for a commercial product that has 2 compiled binaries and no apparent business entity to back them up or support them. A random anonymous email on the repo and licensing happens through a telegram bot. The poster has no real community interactions and nothing that says hey we should pay this person much less put their compiled binaries on our systems. If you are going to release software either show the code or at least be part of the community so people have some faith in what you are making. If you are going to provide a commercial product have the infrastructure and presence to back it up. Not telegram bots and anonymous emails. A domain is like $8.
I hear your point, and you’re entirely right that the optics and architecture of this are massive red flags for a production environment.
My initial thought process was simply that we are always managing risk—even the FreePBX ecosystem itself has a history of CVEs and unverified supply chain dependencies, so I didn’t immediately weigh these binaries as an apocalyptic threat compared to the baseline.
However, I completely concede your point: a visible, patchable risk profile (open source) is a totally different beast than an invisible, un-auditable risk profile (anonymous closed-source binaries). I’ve updated my original post to include strict security caveats, emphasizing that this should only be sandboxed and never dropped blindly onto a production server. Appreciate you keeping the standards high.
Did you actually test this and understand how things work with FreePBX?
This will always show inactive because the asterisk service isn’t used to manage starting/restarting/stopping Asterisk. FreePBX starts Asterisk using safe_asterisk which has nothing to do with the service unit. This always will say the service unit is inactive, which it should be. However, Asterisk could very well be running just fine.
if ! systemctl is-active --quiet asterisk; then
echo "WARNING: Asterisk service is not running."
fi
FreePBX uses MariaDB so MySql shouldn’t be installed. There’s no need to check it.
if ! systemctl is-active --quiet mariadb && ! systemctl is-active --quiet mysql; then
echo "WARNING: Database service (MariaDB/MySQL) is not running."
fi
Yeah, macro’s have been deprecated since Asterisk v16 and removed in Asterisk v21. Current FreePBX v17 dialplan no longer uses Macro’s but they didn’t change their context names. They just were turned into GoSub’s. So in FreePBX v17 this will fail because it’s a GoSub and MacroExit won’t return you from a GoSub like it does a Macro. Additionally, anyone running Asterisk v21 or higher will have MacroExit error out on them.
[macro-dialout-trunk-predial-hook]
exten => s,1,NoOp(=== Click2Call CDR Fix ===)
; If this is an API call (REALCALLERIDNUM is set), force CDR destination to be the stripped number (OUTNUM)
same => n,ExecIf($["${REALCALLERIDNUM}" != ""]?Set(CDR(dst)=${OUTNUM}))
same => n,MacroExit()
This one really came back to bite me. Moved from FreePBX v16 to v17, and I had lots of custom behavior in conf files that employed Macros. My fault for not doing my homework prior to pulling the trigger. But an easy enough fix once I discovered the situation.