Upgrade MTE from Asterisk 1.4 to Asterisk 1.6

I've switched back and forth between 1.4 and 1.8 a couple times while setting up a new server, and didn't have any noticeable adverse side effects. You'll likely want to remove and reinstall the asterisk webmin module (I did) after changing asterisk so that pbx manager will re-detect the asterisk version and re-write its configs appropriately for the version change. Note that I was doing this on a fresh server without really anything customized yet, so your mileage may vary on an established server, and I'd say do it at your own risk and make sure you have backups just in case.

There may be less dangerous ways to get pbxmanager to notice you have a new version, but I didn't want to take chances on that.

you dont have to remove the module, just install it again through the webmin screen. Any install/upgrade triggers the postinstall script that modifies your files.

Should I be concerned about overwriting existing config files that we may have modified? e.g. sip.conf ?

Hi Jawaid,

You should not delete the module - just install the new version.

Regarding overwriting config files - they don't normally get overwritten since installer tries to recognize whether it is a new installation or not and in case of update it patches what it has to without overwriting. It does the patching based on the version of Asterisk it finds installed on the box. That said - you should always backup your configuration files before the upgrade - we are all human and make mistakes - and that includes the installer :).

Out of curiosity, if I already have the latest pbxmanager when I do an upgrade like this, how do I reinstall it? The file I have on disk to point it at for asterisk.wbm is a really old version because I've done all my updates via the "check for updates" within the app, which automatically installed the new one.

"you dont have to remove the module, just install it again through the webmin screen."

So, actually, I can also just do

yum install asterisk16

as well , right? That seems to be all the webmin screen "System" / "Software Packages" does.

Is this is right, we will give it a try. After making copious backups. ;-)

Jawaid

Last question:

is there a reference of any bugs people have found using Thirdlane with Asterisk 1.6? Or is it pretty stable and good to go at this point?

Jawaid

plenty, including the version that is the RPM (1.6.2.13) apparently has a broken implementation of parking. I know 1.6.2.14 works except for MOH, and the most recent RC3 appears to be working as far as I've tested.

Erik,

What MOH issues have you had with 1.6.2.14 ? We just tested basic MOH on the new version and it seems to be fine..

Our upgrade went relatively smoothly. From the command line I had to do the following:

yumdownloader --resolve asterisk16 asterisk16-addons

to get the packages, then rpm --force -ivh to install them. I did this as y'all warned me not to uninstall 1.4, and some package names conflicted. Then I had to remove some old 1.4 modules.so files from /usr/lib/asterisk/modules and manually update the safe_asterisk script (new one was installed as *.rpmnew).

Of course it overwrote all our provisioning files so we copied them from backup to the user_provisioning directory and that was fixed.

Finally I did a :
yum reinstall pbxm-mt

wherein it patched the asterisk 1.6 files. After that we started up asterisk and it was all pretty smooth from there. G722 / "HD" works and we expect multi-tenant parking to work too (we tested the new parking regime on 1.6 single tenant and it was fine).

All in all pretty painless. Last thing I need to figure out is how to get asterisk14 out of the rpm database since I still can't just uninstall it.

Jawaid

theres a bug where parked calls do not play MOH with the dummy timing source of the dahdi driver. Its fixed in 1.6.2.17-rc3 supposedly. I had to use the pthreads timing source as my work-around but that's not the best solution to the problem.

I always compile asterisk from source, it allows me to deselect those modules that are guaranteed to be problems.. example:

format_mp3.so is nothing but a crash waiting to happen. Why not just de-select it and not compile it so that even when some asshat uploads an MP3 file, its not going to play reducing the risk you have a crash.

I spoke too soon. There is a bug in Asterisk 1.6.2.15 that was introduced:

https://issues.asterisk.org/view.php?id=18185

This breaks blind transfers and some other things.

I need to go to 1.6.2.16 which fixes this. Alex, the newest Asterisk in the Thirdlane repo is 1.6.2.15. Is this something we can correct quickly?

Jawaid

Alternatively, we could downgrade to 1.6.2.14 I think.

Do you guys have any thoughts one way or the other?

they both have the MOH for parked calls problem. I'm running 1.6.2.14 waiting on the 1.6.2.17 to become final.

beware of another bug I've seen occur on 2 MTE installations sofar. Randomly a reload command will result in a locked state where asterisk does not finish the reload and no further calls will process. The only solution is to force a restart of asterisk. If you notice your calls stop working and phones wont register remember this solution.

eeman, what process do you use for compiling Asterisk? I've done modules before by getting the source RPM from the Thirdlane repo but do you get the source.tar.gz from asterisk.org and do it that way? I would prefer to change as little as possible from our current setup to avoid introducing any new issues.

I see there's a package for 1.6.2.11 - did you have problems with that? A backrev to that would fix our xfer issue, but what else would it break?

i download the source from downloads.digium.com and compile and install. I do not mess with the source RPM's because I am not a fan of the trixbox .spec files used to make the RPMS. Additionally repositories do not make for a good downgrade process. As you have learned, you can easily upgrade to the latest repository build only to find out that the maintainer didn't even discover there was a call transfer before releasing it. Now you're stuck. You have no backward recourse to revert those changes. All for what? To save you 15min of typing './configure' 'make menuselect' 'make' and 'make install'? At least with the source code you can immediately revert back if the bugs are too bad. This obviously applies to patch level changes. Upgrading from one major branch to another often requires dialplan changes that can be tenous to revert. Thirdlane was designed long before the ISO came out. IT was designed for developers to build asteirsk and overlay thirdlane on top of it. The ISO and RPMs came about solely because over time, more and more inept people wanted to cut out the middle man and install it themselves. You arent 'going against the grain' by rolling your own binaries :-)

RPMs make sense for things like apache's httpd or vsftpd. They do not chronically introduce new bugs at every release. If you've read changelogs in asterisk it doesnt take long to realize that every version you install is going to have some new bug the last version did not. The strategy is to find the version where the bugs are in applications that don't concern you. In a way its like picking a spouse. Everyone has problems/issues. Its all about picking the person with the problems you're willing to live with.

So, there are a couple reasons I like RPM's but I will look into the source.

Is the .spec file that Thirdlane uses to build their ISOs available?

every SRPM has a .spec file that gets installed into the build tree of /usr/src/redhat/

Indeed however there aren't SRPMs in the repo...

The asterisk16-source package just installs the raw source files into /usr/src.

There are .src.rpm for dahdi and zaptel but that's all.

I'm going to backrev to 1.6.2.11 then figure out how to rebuild from source so we can more finely control versions and patches.

I appreciate all your help so far on this.

There are source RPMs in there, I've built from them before.

http://packages.asterisk.org/centos/5/current/SRPMS/

I have been upgrading a group of STE boxes and everything is going perfect with the exception of the next server on my list. I have been after upgrading Asterisk going to TL and telling it to upgrade to the latest version. Which then detects that i am on 1.8 and updates the system.

My problem is that this server is already on the latest TL so i cannot do the upgrade and have it detect the new version.

Should i simply upload the webmin module into the webmin config like a new install? and that will trigger a re-install and re-detect of the Asterisk version?

Unless of course TL 6.1.1.13 is released tonight :)

Thank you for your help.

Sorry was supposed to be a new post. My bad.

yes, re-uploading the webmin module will initiate the post-install script that does what you are searching for.

dont forget that your inbound routes will have to replace all the SetMusicOnHold with Set(CHANNEL(musicclass)=

Thank you very much.

Is it possible to just edit the route in TL and re-save it?

or does it need to be manually done?

depends on how many routes you have but you do have the option of

go into inbound route...
change something and save..
go back into inbound route..
change it back and save again.

if you dont change something its smart enough to not write anything to the files.
In cases where theres hundreds if not thousands of inbound routes, I use 'vim' to open inbound_actions.include and do a search/replace

Got it.

Again - Thank you