Asterisk Very Unstable

Has any one else had an issue with asterisk 1.6.0.x.

It is going off line left and right. I am running on HP server hardware the same stuff I use for the asterisk 1.4 servers and 1.6.0.x is dropping calls. with only 2-3 calls on the line. It is crashing out under greater loads.

I want to try 1.6.1 rc-1 but you can’t compile the addons yet with the rc1 build or the svn

I have it built on three machines and it is doing this on all of them.

Anyone else having the same issues?

Check out my post on Asterisk and call parking. Consistent crashes on different OS and hardware when you do an unattended call park. Been driving me nuts.

Good luck


Thanks for the reply.

Have you tried the 1.6.1 rc version yet?

Some more issues I have run into with the are.

Astrisk crashes when you run out of g729 codecs some of the time.
I had a vendor last week sending multiple invites on the same call. A bug in there system. But it would take down boxes, but not my 1.4.17 boxs. There is somthing majorly wrong with the sip channels in

I want to go to 1.6.1 rc but I can’t get the addons to build and install when I try. It appears that there is somthing wrong with the addons 1.6.0.x and 1.6.1 with the rc and the svn versions. I have placed a bug report last week and have had no response to it yet.

Any feed back on these issues is apperciated.

I’ve been able to build the addons without too much problem, however I initially had some issues with the older release of MySQL and CDRs with the addons compile.

This is the script I use to remove everything before doing a new compile:[quote]
/etc/init.d/asterisk stop
/etc/init.d/dahdi stop
#/etc/init.d/zaptel stop
rm -rf /var/log/asterisk
rm -rf /var/lib/asterisk
rm -rf /var/spool/asterisk
rm -rf /usr/lib/asterisk
rm -rf /etc/asterisk/*
#rm -f /etc/zaptel.conf
rm -rf /usr/include/asterisk
cd /usr/src/
rm -f asterisk
ln -s /usr/src/asterisk-1.6.1-rc1 asterisk

What are the errors you are getting with compiling the addons ?


BTW. I am finding 1.6.1-rc1 just as problematic so 1.4.23 it is for me. I grabbed some stuff from 1.6 and compiled it in the 1.4 to give me what I need. Specifically the DEVICESTATE and EXTNSTATE functions


So are you saying I may have to wipe the system to get things to build?

Here is what I get when I try to build the addons.

zkt-ph-sw0003-gr44:/usr/src/asterisk-addons- # make
CC=“gcc” CXX=“g++” LD="" AR="" RANLIB="" CFLAGS="" make -C menuselect CONFIGURE_SILENT="–silent" menuselect
make[1]: Entering directory /usr/src/asterisk-addons-' gcc -g -c -D_GNU_SOURCE -Wall -c -o menuselect_stub.o menuselect_stub.c gcc -o menuselect menuselect.o strcompat.o menuselect_stub.o mxml/libmxml.a make[1]: Leaving directory/usr/src/asterisk-addons-’
menuselect/menuselect --check-deps menuselect.makeopts
Generating embedded module rules …
make[1]: Entering directory /usr/src/asterisk-addons-' make[1]: Leaving directory/usr/src/asterisk-addons-’
make[1]: Entering directory /usr/src/asterisk-addons-' make[1]: Leaving directory/usr/src/asterisk-addons-’
make[1]: Entering directory /usr/src/asterisk-addons-' make[1]: Leaving directory/usr/src/asterisk-addons-’
make[1]: Entering directory /usr/src/asterisk-addons-' [CC] chan_mobile.c -> chan_mobile.o chan_mobile.c: In function âmbl_readâ: chan_mobile.c:778: error: incompatible types in assignment chan_mobile.c:780: error: incompatible type for argument 2 of âreadâ chan_mobile.c: In function âmbl_writeâ: chan_mobile.c:816: error: incompatible type for argument 2 of âmemcpyâ chan_mobile.c:827: error: invalid operands to binary + (have âunion <anonymous>â and âintâ) chan_mobile.c: In function âmbl_load_configâ: chan_mobile.c:2000: error: âDSP_FEATURE_DTMF_DETECTâ undeclared (first use in this function) chan_mobile.c:2000: error: (Each undeclared identifier is reported only once chan_mobile.c:2000: error: for each function it appears in.) make[1]: *** [chan_mobile.o] Error 1 make[1]: Leaving directory/usr/src/asterisk-addons-’
make: *** [channels] Error 2
zkt-ph-sw0003-gr44:/usr/src/asterisk-addons- #

Most of the compilation problems I had were due to the wrong version header files mucking up my builds between different versions. By running my cleanup script, and rebuilding asterisk every time, I was guaranteed a fresh install without anything left over from old installs to stuff things up.

IMHO If you remove and rebuild, especially if you are jumping between release versions, you are going to be much better off. Deleting the old build completely and rebuilding from scratch worked pretty much every time.

Dont forget to save your dial plan and other such files first :open_mouth:

Good luck

Can I delete the current versions while they are running in memory? Usually when I deploy into production I just do the make install and let it overwrite what is there. Will ther be any file locking issue?

Hmmmmmmm :blush:

So the exisiting system is live ??? :open_mouth:

Thats a good question. usually I build and test off line and then schedule a build after that when everyone is at home with their loved ones and I’m here with the cleaners :confused: At least I get to play loud music that I want to hear

You should be able to delete the header files to help with the compilation issues without affecting the running version.

The problem with doing a make install over the top is going to be leaving old v1.4 modules when you install 1.6. I had some problems when I did that.

Have you got the opportunity to build it on another machine to test prior to deployment on the live system ??

If you are dealing with a live deployment, I would:
[ul]create a couple of scripts to autmatically backup the config, clean the install and rebuild / recopile the new version and your old version from the source.
test the script on a test server
Test the build on a test server
Run the script on the “real” server

It will take a while to compile and install. You will be off the air while that goes on. But when you return from getting a coffee, it should be up and running.

Thank you for your advise. The issue is I am running a public VOIP service. I usually install the new version once I have tested it in development. Then I issue a restart when there is no load on the systems. I can’t do the script thing and wait for the compiles. The weird issue is the boxes are on this should be a simple inplace step up.
As I see it there is some kind of major issue in deploying the 1.6.1 version. The 1.6.x verison is starting to look like a really bad move. in stability

OK then.

if it is a public VOIP service, you are going to have to schedule a outage.

You can either build it on a new system and repoint the DNS to the new box (dont forget to drop the TTL on the DNS record) or have a new box ready to go and swap the blue cable over (you may get some ARP issues)

Or you will be down for 10-30 mins while the software rebuilds. Shouldn’t be too much of an issue during the evening or early AM if people know about it

BTW I’d stick to 1.4.x

I would leave 1.6 alone for a while though if this is a production system. Too many issues, Just flick through the forums and see. I have decided to leave it and kept going on 1.4.x

Good luck


Thanks for your help. it appears that if you are installing the 1.6.1 rc-1 version or any 1.6.1 x version and you want the addons to build you must be using 1.6.1 x version of the addons as well. No where did they state this or offer this version when they announced the 1.6.1 rc-1. Once I got one of the developers to look at the errors I was posting. They knew right off what the issue was. I hope thier response helps some one else avoid the week of headaches… When using the correct version I can build in place like I have always done.


This is because you have to use matching branches. For example for Asterisk 1.6.1 you need to use asterisk-addons 1.6.1, you can not use asterisk-addons 1.6.0 with it. You can get asterisk-addons 1.6.1 from subversion using:

svn co … ches/1.6.1 [^] asterisk-addons

This will check it out into the asterisk-addons directory. I have confirmed it builds against Asterisk 1.6.1 happily.

:blush: I sorta figured that one out. I’m sooo sorry I didn’t mention it / ask you before. That’s what I assumed you were trying to compile.

Never assume…otherwise it makes an ass out of u and me :confused: I’m glad it worked out in the end anyway :smile:

I have had some luck with getting some 1.6 bits compiled under the 1.4 branch, by copying the application.c to the appropriate spot in the 1.4 source, but they were just the simple EXTSTATE and DEVSTATE functions.

Good luck. Let me know how you go with 1.6.1.x Based on the issues I have had, I’m sticking to 1.4.xx for production, but looking forward to 1.6


I will keep the forum updated on my 1.6.1 adventures. I really need to move to it in full production ASAP right now I have a limited set of servers running the code and they work well about 98% of the time with nightly restarts. I am shooting to get rid of the nightly restarts and fixes for the g729 issues I am having. I really want to use the multi parking light but based on posts I have not gone there yet and won’t until the rest is stable.

I just wanted to drop an update in here. I have now pulled all but one server out of production. They were just way to unstable. I am testing rc-1 and 1.6.1 rc-1 to see if either are ready for production use. If anyone else is testing please let me know your feed back as well.