PIONEERS Asterisk 17 Upgrade for Incredible PBX 2020

[wardmundy]

@Samot: These menuselect options were what got loaded automatically using the prior settings from Asterisk 16. The noload options probably were not set in modules.conf because we load a snapshot of the /etc/asterisk directory. I'll check on all of this today and provide an update.

 

[wardmundy]

So here were a couple of issues with a couple of solutions. If you've already run an Asterisk 17 upgrade with the original tarball and script, that created all three voicemail modules in /usr/lib64/asterisk/modules, and rerunning the script after deleting the odbc and imap voicemail options in menuselect didn't fix things because make install doesn't clean out the existing modules. SO.. the simple fix is to issue the following commands:

rm -f /usr/lib64/asterisk/modules/app_voicemail_odbc.so
rm -f /usr/lib64/asterisk/modules/app_voicemail_imap.so

Asterisk 17 also had a change of module naming nomenclature (again) so the correct modules didn't get noloaded in /etc/asterisk/modules.conf. If you don't use the approach above, you can add the following to modules.conf:

noload = app_voicemail_odbc.so
noload = app_voicemail_imap.so

Using either alternative, voicemail works once you restart Asterisk: fwconsole restart

Neither fix should be necessary on a clean Asterisk 17-free server if you download the fixed upgrade-asterisk17.tar.gz

 

[Samot]

If you need to start from scratch you need to do `make uninstall-all` it removes the entire Asterisk install including binaries, etc.

 

[wardmundy]

Just tested using the latest upgrade-asterisk17 tarball on a clean Incredible PBX 2020. It now works as expected including voicemail. No further patches are required. Thanks, @Samot for the tips.

 

[kenn10]

Just tested using the latest upgrade-asterisk17 tarball on a clean Incredible PBX 2020. It now works as expected including voicemail.

Yes. I upgraded successfully. Now I have an issue that no messages about call processing are written to the CLI or the /var/log/asterisk/full log. It is like verbosity is set to zero but increasing verbosity has no effect.


Update: My /etc/asterisk/logger_general_additional.conf and /etc/asterisk/logger_general_custom.conf files were empty. This may have been from my earlier removal of the Asterisk 17 upgrade. I added this back to the /etc/asterisk/logger_general_custom.conf file and it is working now:

[logfiles]
fail2ban => notice,security
console => debug,error,notice,verbose(3),warning
full => debug,error,notice,verbose(3),warning

 

[kenn10]

If you need to start from scratch you need to do `make uninstall-all` it removes the entire Asterisk install including binaries, etc.

I suspect this is what wiped out my /etc/asterisk/ conf files. I don't recommend anyone using this unless they want to completely wipe out Asterisk and all the conf files.

 

[Samot]

I suspect this is what wiped out my /etc/asterisk/ conf files. I don't recommend anyone using this unless they want to completely wipe out Asterisk and all the conf files.

Well this is for non-production machines. You could also backup the /etc/asterisk directly for all your configs and move them back later.

 

[wardmundy]

Just to repeat, none of this is required if you weren't one of the first pioneers. The tarball now has been fixed. So just follow the steps in the first post of this thread.

 

[Samot]

Again, and I'm not trying to rain on any parades, but this might all be moot considering the status of Asterisk 17 and the fact it will be SFO in roughly 60 days. At this point, I would just skip it for anything production.

 

[kenn10]

Since Asterisk 17 is working well, moving to Asterisk 18 should not be too difficult when there is time to experiment with it.

 

[wardmundy]

If you look at the history of most releases, it has often taken a year or more to get to a stable platform. We think Asterisk 17 meets that standard. When Asterisk 18 is stable, we’ll join the party. In the meantime, Asterisk 16 is an equally good option and frankly Asterisk 17’s feature list is fairly small. We just thought some might like to experiment with the latest and greatest... Sangoma/Digium timetables notwithstanding.

 

[Samot]

If you look at the history of most releases, it has often taken a year or more to get to a stable platform. We think Asterisk 17 meets that standard. When Asterisk 18 is stable, we’ll join the party. In the meantime, Asterisk 16 is an equally good option and frankly Asterisk 17’s feature list is fairly small. We just thought some might like to experiment with the latest and greatest... Sangoma/Digium timetables notwithstanding.

If you look at the history of releases Standard releases have a 1 year cycle then they go to Security Fixes Only for 1 year than End of Life after that. Long Term Support released have a 3 year life span, SFO for a year, EOL after that.

All released to the public are *stable* releases. They do RC released as well. So I guess I need to understand what you mean by stable? Both Standard and LTS have a 4-6 week release schedule during their life span for bug fixes/updates. New features are not released during this cycle.

 

[tbrummell]

Update: My /etc/asterisk/logger_general_additional.conf and /etc/asterisk/logger_general_custom.conf files were empty. This may have been from my earlier removal of the Asterisk 17 upgrade. I added this back to the /etc/asterisk/logger_general_custom.conf file and it is working now:

[logfiles]
fail2ban => notice,security
console => debug,error,notice,verbose(3),warning
full => debug,error,notice,verbose(3),warning

I don't think this was related to your upgrade as my server hasn't logged anything since yesterday, after it ran the update scripts upon login. I suspect this may be a proplem with the patch @wardmundy has pushed. Maybe because I had already manually updated logger_general_custom.conf myself. That file is currently empty on my system, and logger_general_additional.conf is populated.
EDIT: I have *not* attempted the Asterisk 17 upgrade...
2nd EDIT: I also updated modules via Module Admin yesterday, which were all CDR related. Maybe that pooched it?

 

[wardmundy]

If you look at the history of releases Standard releases have a 1 year cycle then they go to Security Fixes Only for 1 year than End of Life after that. Long Term Support released have a 3 year life span, SFO for a year, EOL after that.

All released to the public are *stable* releases. They do RC released as well. So I guess I need to understand what you mean by stable? Both Standard and LTS have a 4-6 week release schedule during their life span for bug fixes/updates. New features are not released during this cycle.

What I mean by stable is production-ready. And we all have different tolerances for that. The current changelog for Asterisk 17 is now over 90,000 5,000 lines long. Others might label them as improvements. I'm used to phone systems that last for decades, not months. So we obviously have different expectations as to when an Asterisk version is suitable for deployment. IMHO Asterisk 17 is just getting there, and I don't much care about Digium's EOL timetable... once it's stable by my definition, not yours or theirs.

Corrected changelog length after @Samot spanking.

 

[wardmundy]

I don't think this was related to your upgrade as my server hasn't logged anything since yesterday, after it ran the update scripts upon login. I suspect this may be a proplem with the patch @wardmundy has pushed. Maybe because I had already manually updated logger_general_custom.conf myself. That file is currently empty on my system, and logger_general_additional.conf is populated.
EDIT: I have *not* attempted the Asterisk 17 upgrade...
2nd EDIT: I also updated modules via Module Admin yesterday, which were all CDR related. Maybe that pooched it?

Just did a fresh Incredible PBX 2020 install followed by an Asterisk 17 upgrade. All of the latest FreePBX modules were in place as well. Both log*_custom are empty and both log*_additional are populated. CDRs and CELs work as advertised.

 

[Samot]

What I mean by stable is production-ready. And we all have different tolerances for that. The current changelog for Asterisk 17 is now over 90,000 lines long. That's a lot of changes.

OK, Ward it is clear you actually don't understand or have read the changelogs that are released with Asterisk. The changelog is 90,000 lines long because it covers multiple years of changes. The one in your link goes back to 2013 with changes from v12. So that log includes changes from v12 to the current v17 version it was released with. You honestly think that between Oct 2019 and now Asterisk 17 had 90,000 lines worth of changes detailed in that log?

I'm used to phone systems that last for decades, not months.

Then you must be referring to hardware based PBX systems. I have plenty of end users with 30+ year old Mitels. However, this is a software based PBX which could go into a hardware based system or a virtual system. Software based systems have updates to the software.

This is a poor argument point for someone that has been releasing various software PBX systems for the better part of the last decade or so. One would think you've come to terms with the fact that software PBX systems require updates on a regular basis.

So we obviously have different expectations as to when an Asterisk version is suitable for deployment. IMHO Asterisk 17 is just getting there, and I don't much care about Digium's EOL timetable... once it's stable by my definition, not yours or theirs.

Yes, we clearly do. You expectations is that a release with a 1 year life span is "just getting there" 10 months into its life span. But hey when support/updates/bug fixes are all dropped for it in 2 months, it will definitely be production ready.

Let me ask you a question, how many (and how often) have you run straight Asterisk systems that weren't packaged into a PBX system like FreePBX? How much experience do you have with Asterisk itself and using it, not just how another vendor deployed it with their PBX software?

Because I agree with what you have said before, Chan_PJSIP was just plain awful in FreePBX back in 12 and 13 but not because Chan_PJSIP was bad, it was how it was used by FreePBX. I ended up just using Asterisk/Chan_PJSIP on its own without FreePBX in the middle doing stuff to learn and fully understand Chan_PJSIP when it first came out.

 

[wardmundy]

@Samot: I'm not sure we're getting anywhere in our discussion. What sane company would ever produce a PBX development platform with a one-year life span? We've been saying that for more than a decade so you're preaching to the choir. We offer Asterisk 16 and Asterisk 17 solutions now. Unless you know something that I don't, those are the only available Asterisk choices at this juncture.

If you don't like the Asterisk 17 EOL timetable, there's still Asterisk 16, and we support it. I'm glad you like PJSIP. I'm glad you like rolling your own PBXs from Asterisk source. We do, too. We've gone a different route using the FreePBX GUI. Our platform is very stable and secure. And it's easy for most folks to use. You prefer to roll your own and apparently don't like FreePBX. That's perfectly fine, too. We've strayed way off topic at this point so perhaps we can just agree that your way is better for you and call it a day.

 

[dhoppy]

I just ordered this for my car, "SAMOT's WAY IS BETTER" wouldn't fit.

 

[Samot]

I just ordered this for my car, "SAMOT's WAY IS BETTER" wouldn't fit.

View attachment 2967

My way of what, exactly? In regards to this conversation and thread I have not once said "You should do it this way because that's how I do it and it's better." in any way, shape or form.

Let's be clear on something, I pointed out a simple fact: Asterisk 17 will become Security Fixes Only in roughly two months. I *suggested* just skipping it for any production machines at this point because of that fact. The response that I got was that it takes a year for it to be stable. That is incorrect. The claim that Asterisk versions are not production ready when released. Incorrect. The claim that the 90,000 line change log indicates a lot of changes for Asterisk 17. Highly incorrect, it's historical.

So since, as I pointed out, I have in no way declared "SAMOT's WAY IS BETTER" it makes your little zinger silly as it based on no context in this conversation. However, since you have decided to interject yourself in the conversation with the only intent to "zing me" I will ask a simple question. What flavor of Kool-Aid is your favorite?

 

[dhoppy]

Fruit punch.

I know it is obscure, but the last line in Ward's reply was "perhaps we can just agree that your way is better for you and call it a day."

It was intended to be silly, because I thought the debate was silly. Forgive me if I triggered you.