This post was flagged by the community and is temporarily hidden.
Unfortunately, I don’t think this will ever be possible due to mostly security concerns. Instead may I ask what part of Sysadmin should be open source?
If I were experiencing show-stopping bugs with pjsip, yes, I’d use chan_sip. But I haven’t used it on an installation in 2 years or so now. I acknowledge that some people might have situations where they are encountering bugs, and chan_sip might work better for them.
To be clear about my request – and I think you know what I meant – I was saying that if someone is writing here about a configuration issue and you are recommending chan_sip to them, it ought to come with a specific bug report about pjsip, not just a search for pjsip on the asterisk bug tracker.
(A similar search for “chan_sip” in the bug tracker also produces a large list of open bug reports.)
All of it. We all know it is obfuscated for mostly business reasons. There is no argument for security through obscurity imo.
Even ignoring my suggestions, chan_sip will still be available for people to select as their primary SIP driver. All that they’ll need to do is go into the advanced settings module and enable it.
And that ties in nicely with my suggestion about educating new users during the install and allowing them to make a choice.
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:
chan_sip is dead. Move or don’t update once it is gone completely. This really is not a debate.
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.
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.
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