I would like to announce that GABPBX is now publicly available on GitHub:
GABPBX is a PBX project created and maintained by Germán Luis Aracil Boned. It is based on Asterisk 1.8, while preserving the original Asterisk copyright notices, GPL license terms, Digium attribution, and original author credits.
The main current development focus is chan_sofia, a new SIP channel driver based on the Sofia-SIP library. The goal is to provide a chan_sip compatible replacement while using Sofia-SIP for a cleaner and more modern SIP implementation.
Current chan_sofia highlights include:
Sofia-SIP based SIP signaling
chan_sip style peer configuration through sofia.conf
Existing dialplan compatibility using SIP/peer
Dynamic peer registration
Multi-contact support
Realtime sippeers and sipregs
NAT handling with force_rport and comedia
Digest authentication with MD5 and SHA-256
SIP blacklist protection for repeated bad registrations
TCP and TLS signaling support
WS/WSS signaling groundwork
SRTP integration
Opus codec support in GABPBX
Improved CLI output for peer inspection
Compatibility work for existing chan_sip deployments
The project is under active development, especially around SIP compatibility, transfers, NAT, media negotiation, realtime operation, and production robustness.
Feedback, testing, bug reports, and patches are welcome.
This is going to cause confusion if people come here for support, as you are not going to accurately emulate chan_sip. and people rarely say what channel driver they are using.
Why chan_sofia? Because the pjsip implementation is complex and very inefficient. I’ve brought something good from FreeSwitch over to Asterisk. It compiles with the same library used in FreeSwitch. And it’s simply wonderful to be able to fix bugs without having to hear: “Better not, because people already know what the bug is, and fixing it could cause problems.”
That is an opinion that’s probably not shared amongst the base. I’m more curious about the almost decade plus of other improvements and features in Asterisk. The CDR/CEL overhauls, changes to AMI (plus now having ARI), the internal API updates and all the other goodies.
For me the whole Asterisk 1.8 part is a non-starter regardless of the SIP channel driver.
The Astrisk project deprecated then removed chan_sip. Users who do not wish to switch to chan_pjsip are doing 1 of 4 things
Still running Asterisk 21 which still has chan_sip
Using the USECALLMANAGER patch which now incorporates chan_sip in it (meaning if you apply the patch to Asterisk it brings chan_sip into it
Using the maintained fork of chan_sip which has some fixes in it regarding faxing, etc. This must be patched into Asterisk
Not upgrading.
There’s been many posts from people needing assistance to migrate from chan_sip to chan_pjsip in both this forum and the FreePBX forum. Most of these people have been helped. Only a very few border cases were unable to migrate due to esoteric hardware (doorphones, for example) that didn’t follow the SIP standard properly.
There have also been changes in chan_pjsip over time that have increased interoperability. For example at one time it was not possible to build a functioning trunk connection to a Cisco VoIP router using chan_pjsip however now it is.
I have always wondered if FreeSwitch was actually a fork of Asterisk. They claim it is not - but - the fact you chose such an older version of Asterisk makes me wonder if you did this because the Asterisk 1.8 code is much more similar to FreeSwitch than the current Asterisk 22 code.
The one thing that might come out of this is with that old an Asterisk version you can graft in the old AMP code which later became FreePBX - it’s still out there:
Look, all I’m trying to do is offer the chance to spin up an alternative project to Asterisk and try to do it better — more robust, higher quality. GABPBX builds cleanly with GTK3 for menuselect and zero warnings on a fully up-to-date Arch Linux, which is my daily driver.
If chan_sofia — and that’s just one of the bits I’ve folded into gabpbx over the best part of 20 years — can help us ditch the pjsip monster, or kick off a proper fork even under a different name, I’d be more than happy to pitch in. I just want to share my work so the rest of the community can get some mileage out of it.
I’ve got systems running on this codebase in production, with thousands of users and calls going through them. Realtime has been substantially improved, with proper caching. Both before and still today, Asterisk fires off more than one SQL query for every dial plan line it executes. With mine: zero SQL statements. That’s the kind of thing I think we can be doing better. And it’s not the final word either — I’m planning to push it a lot further across the board, and ideally land a clean, no-fuss migration path from chan_sip to chan_sofia.
Do whatever you like with it. That’s why I’m putting it out there.
What about all the other non chan_sip stuff? What kind of work has been done on the rest of Asterisk because a SIP driver alone doesn’t make this a real solution.
Please don’t get defensive. There’s nothing wrong with a maintained fork of any open source project but your initial post here didn’t indicate that this project has had any mileage on it at all. Every year we have guys who pick up a C compiler and try forking existing open source projects. Most of the time, those projects die and the effort they put into them ends up wasted. Even when they do succeed, it is oftentimes not a benefit to FOSS overall.
For example I’d point to pfsense and opnsense and Untangle. All 3 purporting to be better FOSS firewalls. One of them, opnsense, a fork of pfsense. It would have been better in the long run if 2 of these projects had never existed because the 3 of the sliced up the FOSS firewall market to the point that none of them ever gained significant traction to compete against fortigate/palo alto/cisco/etc. effectively.
The VOIP market is different and definitely can support more FOSS projects if there’s a clear compelling reason for the fork. The people here have thrown out some valid concerns with a fork based on an old Asterisk version. But you said this project has been in development for 2 decades thus the fork occurred long ago - thus the reason it was forced from Asterisk 1.8 - so - certainly those issues have been looked at and addressed, correct?
I spent a bit of time today trying to figure out if anything in the core (basically the main directory) was substantially different than what is in Asterisk 1.8 and I am not seeing much. It is possible I’ve overlooked something, so I won’t claim to be 100% certain.
I’ve seen this movie before… someone grabs an old codebase, bolts on a few shiny bits, breaks half the assumptions that modern asterisk has spent years moving away from and then declares victory… God bless their hearts