So I am very curious as to what people’s “Long Term Solution” plans are with FreePBX. I’m not talking about Sangoma’s, I’m talking about us, the users.
Asterisk is seeing a lot of changes and some of these plans I’m pretty sure where in place before the Sangoma buyout. I’ve noticed that since moving to Asterisk v16 I’m now seeing a ton of these:
app_macro.c: Macro() is deprecated and will be removed from a future version of Asterisk.
Not much can be done about that in general as FreePBX relies a lot on Macro()'s for core functionality. Until those are replaced with GoSub()'s it’s just going to be a thing that exists.
The biggest change that will be coming down the road is the fact that Asterisk really doesn’t require a need for two SIP drivers. This means Chan_SIP is on the chopping block because much like Macro()'s it is deprecated and has been now for four years. It would seem there are talks about moving Chan_SIP to no-load (which is what app_macro.so is now for new Asterisk installs) meaning that the user would have to enable the chan_sip.so module to run it. Even more there are rumblings that Chan_SIP will be going away very soon, probably even with the next LTS release. (I’m speculating. Do not take it as gospel). I’m sure that Chan_SIP will continue to be functional in FreePBX until such time as it is completely removed from Asterisk.
Which brings us back around to my original question. What are the plans? I’m still seeing people using Chan_SIP on new installs. I’m pretty sure people are still using Macro()'s and other deprecated functions in Asterisk.
I mean I get the whole “if it works don’t touch it” logic and that’s fine but I have watched people over the last four years not make adjustments for the changes in Asterisk. Some stayed on v11 until the last moment, some sat around and didn’t touch PJSIP at all including even learning about it. In all those cases they were bitten in the ass by it because when they did update (forced or by choice) they did it blindly and had no idea what they were getting into.
So the writing is on the wall, things are changing and in the next 2-3 years things that have been a part of Asterisk and how people do things will be removed. Don’t get caught with your pants down and thing “I have time” because you are going to need the time to learn, test and understand how PJSIP and Chan_SIP differ and how to make adjustments for that. Otherwise you end up making the move, having a ton of issue then rolling back because “urgency” and not have any testing or debugging on hand as to why it doesn’t work.
For me, my systems will be a 100% PJSIP by the end of 2018 and I will be spending as much time in 2019 working with my underlying providers and MSPs to get all of them moved to PJSIP.
Well one should just build app macro you still can do this. To be honest the Asterisk development team warned us about this for quite a long time and FreePBX never did anything about it
Sure but I can tell you that FreePBX’s long term goal is to break out the channel drivers in Core. This is largely already done and was started 4 years ago by @xrobau and I. Once this is completed then there will be a freepbx chan sip module. You want chan sip? build Asterisk with chan sip and install the FreePBX Chan sip module. You could also utilize this in the sense of Chan SCCP… @cynjut
The FreePBX distro will continue to support app_macro and chan_sip for a while. At least until we change macros to gosubs. Chan SIP will become deprecated from FreePBX at some point but not without warnings and it’s code will go into the sub-module hook into core.
Yeah, not a problem. I figured this stuff was on Sangoma’s radar and being dealt with. I’m just really curious about what people are going to do. Like will people stop upgrading Asterisk/FreePBX just to keep Chan_SIP going? What happens when Asterisk no longer has Chan_SIP?
Like I stated, I figure as long as Asterisk has to ability to run Chan_SIP FreePBX will continue to support it in some method such as the module you are talking about. There will be a point though where Chan_SIP just doesn’t exist in Asterisk anymore. It’s that kind of thing I’m curious about.
I just have the opinion now that approaching Asterisk with a pre-v13 mentality is just going to be more trouble than it is worth in the long run. Asterisk has made some significant updates and changes in the last 5 years, not considering or even embracing the new methods and features is just a waste.
I don’t know, that kind of thing needs to be qualified. Is it a home/personal/hobby system that is just there and hasn’t been touched? Is it a production system that a business(es) are depending on for their voice service?
If it is the former then whatever, that’s not really relevant to this. If it is a latter, I would consider it an issue.
What’s the point? This benefits no business service ever.
So much implied wrongness out of that statement. I mean, I only know you from postings here, and I know you actually know what you are doing with these systems. But this type of attitude seems pervasive of so many people that don’t actually know anything.
Not virtualized (assumed based on “basic box”)
Direct cost: Waste of power/money
Indirect cost: loss of flexibilty in recovery options.
OS not rebooted.
You have no idea if the system could actually reboot after a failure or not. Will it? maybe. But you do not know.
Huge security holes because the system updates have obviously never been applied. That would require a reboot. Not every update does, but certain ones do (kernel).
Super old everything. Brain just melts.
Ungodly old version of asterisk, similar subpoints as the ones in point 2.
Alright, please don’t do this to the thread this early on. Give it time. @cynjut asked a question, I asked for qualification, he gave it. The system in question does not relate to this overall. A hobby/personal system running ancient software/hardware for the sake of “seeing how long it lives” is fine and well for those kinds of things.
Have this reaction when someone says “in production”.
While I agree that it’s good to be up to date with your PBX and reboot your machine every time you apply kernel or asterisk updates, but we also have 2-3 critical machines that can never really be rebooted, and I believe there are more people here who have at least one setup like this.
You mentioned that it does not seem like “you know what you do” if you never apply updates or reboot the machine, which is obviously a security risk.
I know i know… But if you block internet access, the machine can’t access the web, 5060 and RTP is only open to the SIP Provider. Then what security/issues is really there?
We do have a warm spare and proper backup in place.
Again, I do agree that best practice is to be on a supported version of FreePBX/Asterisk and be up to date.
But I also understand the people who sometimes can’t update, but in the same time take the proper precautions to prevent security risks and have a backup plan.
Most of our servers are already FreePBX 13 + Asterisk 13 +
And we do plan on upgrading the rest very soon, for some, we might actually wait for FreePBX 15 which will make the process easier.
My money is on it sticking around until at least Asterisk 20 in some form. Perhaps it will end up as an add-on or contrib module similar to ooh323. As long as the channel module C API remains backward compatible there’s not a lot of reason that chan_sip should be removed by force. There will be die-hards.
For some people, moving over to chan_pjsip will only happen when pjsip has a feature they want that chan_sip doesn’t have. I believe we saw that recently in a project that shall not be named.
I hope it’s not something as mundane as the SIP channel driver but rather something more interesting like rest APIs or other sophisticated integrations that keep people moving ahead.
It already is. All improvements, bug fixes, etc on Chan_SIP after August 2014 has been 100% community contributed. Digium has not actively developed, fixed or done anything with Chan_SIP since that point. Based on dev notes I’ve seen in blogs and on the wiki the talk is that Chan_SIP will be no-load as of v17 so that is the next “Stable” release and even if it is Asterisk 20 that’s still just 4 years away. As I pointed out in my original post, people sat around for 3-4 years after v12/v13 to make the leap and found themselves in horrible positions due to waiting to the last might to start learning as they go with the migration.
What features are those? Was it the whole FQDN issue with the external addresses? Not being able to do lookups against the FQDN’s? I mean that was one of my major hold outs except that problem has been fixed for a year almost now. The fix was release in January of this year.
Let’s be honest, the project that shall not be named was half-assed. The person that lead that here was still asking questions and didn’t fully understand PJSIP in Asterisk so that was clearly reflected in the project.
Also, if people are basing what PJSIP can and can’t do based on using it only via the FreePBX GUI then they are sorely uneducated as FreePBX’s implementation is limited and doesn’t use or give you the best ability to override it but my testing of PJSIP outside of FreePBX (i.e. I control everything for it’s config) is rock solid and pretty much out performs Chan_SIP.
There are numerous reasons for Chan_SIP to be removed with one of them being it is a sub-par SIP driver in the world of SIP Drivers. However, as I pointed out earlier Asterisk does not need two SIP drivers. The fact that Chan_SIP has existed since the inclusion of PJSIP is so that people would have time to learn it and migrate. It’s been 4 years now and by the time it is actually removed it will be between 6-8 years since the inclusion of PJSIP and over a half of a decade to make the move is more than enough.
So again, Digium hasn’t touched it since 2014. Sangoma hasn’t touched it in years, all their development is and has been PJSIP focused. With Sangoma now owning Digium and both of them having the same views on Chan_SIP’s lifespan and use the die-hards are going to have to deal because maintaining and supporting Chan_SIP will (if it hasn’t already) be a drain and has no added value for keeping it in the long term.
No, I was asking what people’s long term plans are for managing their FreePBX boxes with the fact that as of v16 is seems that deprecated things like Macro() and Chan_SIP are tagged for removal.
you still can do this. To be honest the Asterisk development team warned us about this for quite a long time and FreePBX never did anything about it