I think this is the right section since it involves upgrading.
I am proposing that there is some sort of thread/blog that informs this community of when to update their versions of Asterisk because that version release fixed bugs or improvements or feature adds. Just making the new version releases in the repo isn’t enough if people don’t know that getting those versions solve issues or can enhance their current setup.
Here are two examples for context.
Chan_PJSIP transport option ‘allow_reload’ would let you reload transport settings without a full restart. There was a downside, it could (and did) impact active dialogs/transactions because the transport goes away and comes back. That feature has been around for a while and because it has never worked right, the answer was always “Don’t use it, it can break calls”.
As of Asterisk 16.18.0, 18.4.0 and 19.0.0 this issue has been resolved. When setting allow_reload=yes it will do a partial reload of the most commonly updated settings such as local_net’s, external media/signaling, domain. Thus it no longer requires a full restart to update LAN network details or WAN details for NAT.
RFC4235 Support Issues. - This is what has been impacting call pickup information with chan_pjsip. It had partial XML support for the information of what watchee was being rung and the callerid information of the caller. So you could see a BLF line was being rung but had no details on the caller/call. Someone submitted a patch for this a while back, it needed some work and it finally got some to be acceptable for mainline.
As of 16.19.0, 18.5.0 and 19.0.0 this patch has been brought into the mainline.
So these have been in Asterisk for about a year. I’m sure many are running these versions or higher and still don’t know either of these issues have been fixed (or perhaps stumbled over it).
I think it would be beneficial for this to exist here even though it exists at asterisk.org but there are those that don’t follow the Asterisk side and only watch what FreePBX does. This would keep everyone apprised.
Let me follow up with defining “exists here”. Not a copy and paste job of the Asterisk change log. Not everyone will follow that or be able to associate it to FreePBX terms. It needs to highlight the FreePBX impact and resolution, etc. the release offers in relation to FreePBX use cases.
Another thought, It can also touch on feature adds that aren’t in FreePBX yet.
You don’t actually need to set “allow_reload” to “yes” for the partial reload. It will automatically update what it can regardless. Setting “allow_reload” to “yes” actually enables the full behavior and can cause issues.
Some people are going to hate me for saying this, but generally I think keeping up to date on whatever branch of Asterisk you’re using is the best thing you can do by default (assuming it’s a currently supported branch).
There are many schools of thought on this, such as don’t introduce changes in something that’s working well, which I respect - but on the other side, you miss out on a lot of bug fixes that go in every day.
Asterisk’s test suite is also quite robust now, so a lot of bugs are caught before they’re released.
I think that makes a compelling case in favor of updating more frequently as well, as it means that new releases are much safer from a risk perspective than they ever have in the past, and continue to be even more safe as the test suite improves.
Our policy is to wait 30 days and watch the forums to make sure an update does not break anything. Then by all means proceed with the update. We learned this from Microsoft.
If there is no security risk in not doing an immediate update this is our SOP.
I don’t think the point was gotten here based on the replies. This has nothing to do with being on the latest release of Asterisk, keeping yourself updated to the latest release or waiting a time period before updating to make sure there are no issues. This was about informing the user base on what those updates actually do.
The two issues I highlighted where issues in Chan_PJSIP since its inception or the inception of the feature (transport reloads). It took the better part of six years for those issues to be resolved/addressed. During that time period being on the latest version did nothing to solve those issues. Those issues have been resolved for over a year and based on the comments in threads (such as saying you need to restart when updating local networks, etc) means people don’t realize this feature is there and as Josh pointed out, automatic for things like local_net and external details to be reloaded. Doing restarts still is unneeded.
Users can still be on Chan_SIP because of the lack of RFC4235 support. Something that kept me running certain users on Chan_SIP because Chan_PJSIP’s implementation was incomplete. So how many users are still using Chan_SIP for the past year because they couldn’t migrate due to an important feature not working and can now but not realize it?
Even to push this point further. Based on the activity I’ve seen going on another feature that has been lacking in Chan_PJSIP since its inception and stopping many users from outside North America from migration; tel URI support. It seems that tel URI support is being worked on and could be seen in future update releases this year.
So if 16.27, 18.13 and 19.5 (two release cycles basically from now, hypothetically) have full tel URI support when released and people are updating to stay updated. How do they know this update has the support they’ve been waiting for to migrate off of Chan_SIP?
This isn’t FreePBX of yesteryear where the majority of the user base were Asterisk power users looking for easier ways to managing Asterisk. This is modern FreePBX where users want to download a free to use PBX solution and don’t really care or know about Asterisk or how it operates. They have no interest in following Asterisk or caring what it can do. They only care what they can do with FreePBX and thus depend on FreePBX to tell them what that is.
Yeah, I think I see what you’re getting at now - sometimes there are features or bugs that are perceived to be FreePBX features or bugs but are in fact fixed by using newer versions of Asterisk.
And compounding that, FreePBX itself is not forceful about which version of Asterisk is being run. Communicating when an Asterisk version update turns into a FreePBX bug fix or feature improvement is I think what you’re getting at?
Or is it more on the side of your last paragraph, where FreePBX should really be focused on the integrated user/product experience of FreePBX+Asterisk rather than being a little more loosely coupled?
