And that is the same reason that I believe that chan_sip should remain enabled by default in new builds of the FreePBX distro, or that, at least, the user should be given some kind of notice during the installation of FreePBX so that they can make an informed choice.
I recognize that the new user will be able to enable it in the advanced settings module. And you guys will be fielding a ton of such inquiries here in the forums and giving that very same recommendation.
What is being referred to in the amount of deployments with chan_sip still in use. A new user that has never installed FreePBX should not be starting with chan_sip so they can be told to move away from it within the next 2 years. When the goal is to get existing users to migrate the best plan is to not keep adding new users to that list. You stop new deployments from using the thing you’re trying to remove and work on getting the existing people to migrate.
Your suggestion of keeping chan_sip active for people to select as their primary SIP driver is actually adding to the problem of getting people to migrate off of chan_sip.
Your recommendations for chan_sip come with vague claims of pjsip bugs, “not ready”, and etc. Yet when pressed to show the bug reports, there aren’t any. A chan_sip recommendation would hold a lot more weight if you actually showed the open bug ticket(s) supporting your reasoning for using the deprecated driver.
Please link tickets. And then when the bugs are fixed, future readers can see that the recommendation was made while there was a bug but that it was resolved and is no longer an issue.
I only post recommendations that people try chan_sip when people post a comment stating that they’re having trouble with pjsip. Using chan_sip when you have trouble with pjsip is always a good trouble-shooting step.
There’s a post on the forums right now about a pjsip bug relating to NAT. And it is a bug that I’ve seen myself. Here’s one:
Thanks for giving me this chance to convert you. I assume that you’re in my camp now that I’ve given you precisely what you asked for!
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.)
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.
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.
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:
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.
