Suggestions for future versions of FreePBX

Can you show tickets that don’t A) have the author admit it is a one time and hasn’t been reproduced and B) are against an active and supported version of Asterisk. v13 was moved to Security Fixes Only last year, it fully goes EOL in 2 weeks. This ticket was against 13.32.0 which was early 2020, 13 had a few more updates before going SFO and has had SFO updates. v13 is currently at 13.38.3

So current releases of Asterisk and actual, reproducible bugs that actually impact people. Those are qualifiers.

I would say Sysadmin is the anti-opensource module if there ever was one to be honest. There are much better ways to manage a system than using Sysadmin. Using the sysadmin module prevents FreePBX from also working with automation tools such as ansible. If anything I’m more surprised you all aren’t fighting for LESS to be done in Sysadmin, or better compatibility with the way linux machines are typically managed.

Ideally, the whole thing.

System Admin was non-commercial module for the first version of FreePBX that it was released in.

If you are saying that sysadmin should be scraped completely then we are on the same page, as long as whatever replaces, if anything, is open source.

Start by untying the firewall module from sysadmin and/or getting rid of that as well. Both the firewall module and the sysadmin modules are perfect examples of how not to put a GUI on linux.

There are much better ways to do it where it does not get in the way of how linux naturally does it. VirtualMin/Webmin is a perfect example of a project that does not get in the way of Linux. You are still able to do the same things on the command line and the two never fight with each other. Pretty much the exact opposite of the sysadmin and firewall modules.

That’s a totally valid point. I don’t use System Admin at all.

Again, my comments are directed towards ensuring that the project is accessible to new users, and that they can get a system up a running without a large learning curve. Once they have to learn parts of CentOS, all bets are off and they might just head over to 3CX. System Admin is good part of that.

I agree 100%.

Again, I’m not telling anyone NOT to use pjsip. If it works for your situation, that’s great. But, lots of people are reporting that it doesn’t work for their situation. The usual response seems to be to forward all your ports, which is terrible security advice, and is generally not necessary.

Reports of pjsip issues are all over the forum. If you can’t accept these, then I don’t know what to tell you. Again, here’s one from a few days ago, that I experienced MYSELF as well:

dead-horse-spank
chan_sip is dead. Move or don’t update once it is gone completely. This really is not a debate.

2 Likes

Let us not conflate FreePBX issue with chan_pjsip with actual Asterisk chan_pjsip issues. They can be totally different things.

FreePBX writing out Dialplan or configs that are incorrect is not the same as a chan_pjsip bug.

You are the first person to bring that up, and I agree that we should not conflate things that have nothing to do with our current discussion.

Well the forum post you recently linked to has nothing to do with this discussion either. The contact having the local LAN IP instead of the WAN IP could be due to a configuration issue. I see that someone asked to have the output of the transports to confirm their setup but no reply back on that yet. So this problem could be as simple as a user not setting up the proper details in their configs. Until otherwise shown, there’s no proof of anything related to a “bug” with chan_pjsip.

Also, you keep saying that chan_pjsip is new and not mature. It’s eight years old within Asterisk, 16 years old on its own. Chan_PJSIP is as currently almost as old as Chan_SIP was when you totally accepted it was mature and no need to be developed further. I would kindly ask you stop saying things like this as they are incorrect and misleading.

That report was of an intermittent problem. A FreePBX configuration error, or even a FreePBX bug, would not cause that.

But, now that you mention it, I do agree that bugs in the FreePBX pjsip module are also a good reason to keep chan_sip around.

You’re comparing apples and oranges.

chan_sip has been used in Asterisk and FreePBX since day one. Pjsip has not. The argument that pjsip is 16 years old “on its own” is irrelevant. What matters is its maturity on this platform.

Alright, this has become a circular conversation. I’m done with it. You should be prepared for people to be flagging your posts that have inaccurate information on chan_pjsip.

1 Like

The arguments have all been presented and hashed since the early days of FreePBX 13 when the decision was made to bind pjsip to 5060. When judgement is applied about how to proceed, you will always have differences of opinion. I would hope that when people advocate for a particular course of action, that they recognize that it’s their opinion, and that others have different perspectives and different opinions.

I will state categorically that the future of the project is pjsip. And I will state (again!) that chan_sip will be supported as long as is practical, but it’s not a project goal to support it indefinitely.

1 Like

Just my opinion on this issue:

In general, pjsip works fine with endpoints but has problems with some trunking providers and interface devices; there are of course a few exceptions.

For many users, pjsip’s ability to handle multiple registrations is a major benefit, allowing them to have multiple devices with the same extension number. It is also far more robust with mobile apps that switch between local and push server registration and/or between Wi-Fi and mobile data.

Many small systems are on-site with dynamic IP addresses and flaky internet connections. The inability of chan_sip to properly handle DNS SRV records and DNS failures makes pjsip the obvious choice.

Of course, pjsip lacks certain features (tel URI, identify by port, etc.) that renders it completely inoperative with some trunks and devices. Obviously, these should use chan_sip.

IMO problems with using both drivers are very rare. I’m aware of only one provider (Vitelity) and only when used with IP authentication, where the PBX must bind to port 5060.

All of the above relates to features. Bugs are a different animal. I’ll admit that pjsip is presently inferior. There are two open threads about Contact headers intermittently presenting an incorrect address. These guys are in different countries, with different providers and different firewalls. Unfortunately, neither has been helpful in tracking down the bug, so it’s hard to get it fixed.

One thing about this is it gets you closer to key systems which a lot of smaller businesses like

Can you clarify what you mean by “identify by port”? Within PJSIP, the identify support has supported identifying including based on port for awhile now. I don’t know if that’s what you’re referring to, or if supported by FreePBX.

Yes, FreePBX supports it because the PJSIP Trunk fields offer a text field to put in IPs to match against for incoming calls. It probably doesn’t denote that you can do 1.1.1.1, 1.1.1.1/28, 1.1.1.1:5060/32, 1.1.1.1:5060/28.

Yes, there are some things that are missing in chan_pjsip such a tel uri support. That type of thing was most likely deemed a small percentage of use and could be added in the future when there is a demand. I do agree that demand is growing so it could end up being in there. I mean it took until 16.19 or so for the RFC4325 issue to be addressed (proper XML data for NOTIFYs for call pickup). Been working great with the patch and after the patch was brought into mainline. At the same time new things have been introduced in chan_pjsip over the last three releases and FreePBX still doesn’t do anything with them.

So I think this does highlight a big qualifier for this discussion and that is how FreePBX is handling Chan_PJSIP. Because those of us that are using chan_pjsip in a pure Asterisk environment are really not seeing most of the issues using it in a FreePBX setup would.

Honestly, when I started to get as much on PJSIP as possible 3-4 years ago my biggest problem with PJSIP was FreePBX. Once I abandoned FreePBX’s methods, did everything in the custom files and did my own configs, PJSIP work way better and was easier to deal with.

Tom, I’m not sure if you still feel that way, but this is why I suggested moving the pjsip module more towards the way that the chan_sip module works, by creating an open field like the PEER details.

Doing it that way is also a lot faster if you have do to a bunch of different trunks, because can just cut and paste from one source instead of having to input multiple fields on multiple tabs.

(This reminds me of the debate about the “dialed number manipulation rules” changes from 6+ years ago).

And again, this is why it is not yet time to disable chan_sip by default. That day will come. It is not here yet. :slight_smile:

Care to elaborate on that?

The problem with this is that feature requests on the Asterisk JIRA are rejected from community members unless they include a patch. This is not helpful; many end users are quite adept at reporting legitimate bugs and feature parity issues with chan_sip, but don’t have the programming skills or the time to actually write patches to support the development of PJSIP. Closing the tickets prevents us from even getting to first base.

The better option is not to use chan_sip, but to open a Feature Request in Asterisk JIRA, and post a bounty or find someone to write the patch.

Everyone needs to remember that this is an OPEN SOURCE project. As a community, we are getting something for free… If you don’t like something then contribute. Complaining about PJSIP is inappropriate IMHO. Let’s all work together to do this right. The code for chan_sip is horrid and the PJSIP rewrite is long overdue.

1 Like