Here we’ll explain the benefits of upgrading to version 1.8. If you are currently running 1.6 , one of the benefits is that 1.8 is also suported by Digium. Now, how stable is version 1.8 compared to 1.6?
So many new features have been added in 1.8.
Nope, Asterisk 1.8 is not stable enough yet.
On Thu, Jun 2, 2011 at 6:33 PM, Gopal krishnan
what do you mean Asterisk 1.8 is not stable enough yet? Can you give
With due respect to Digium work, are there no issues with Asterisk 1.8?
Are you suggesting that there are no bugs in 1.4 or 1.6?
Currently there seems to be a fear of 1.8. We’re about to put it into
production and yes, we’ve had issues with it, mostly due to the fact we
use RealTime, but before you change anything it is always advisable to
test the hell out of it.
To anyone who is thinking of moving to 1.8 the question is not, ‘is it
stable?’. The question is, ‘have I comprehensively tested it to show
that it is suitable for my needs?’
If 1.8 doesn’t panic for subset of PBX features for someone, you can not say
it is stable. You should also look at other
features and how they work with 1.8.
I didn’t say 1.4 or 1.6 have no bugs or issues. When there were 1.4 or 1.6.0
branches, they did have bugs. But since people
started submitting bug reports, they have become quite stable. They don’t
get crashed as frequently as 1.8 for the same set
of features(You can check it on issues.asterisk.org). When I said ‘Asterisk
1.8 is not stable ENOUGH’, I didn’t mean
‘Asterisk 1.8 is not stable AT ALL’.There are still some feature
functionalities which work perfactaly on 1.4 or 1.6, create
some panic on 1.8. I would consider 1.8 stable enough when anything which
worked on 1.4 or 1.6, also work on 1.8. And I am
optimistic about 1.8 being stable enough shortly.
Let us not start a war on 1.8 stability issue. There were enough threads on
1.8 being production safe in last couple of
months.Mine was just a user experience and personal view shared with
Yesterday my 1.8 got crashed and I have nothing in log or anywhere
which I can show you or submit bug. Kinda funny 🙁
And the first of those is a real show stopper at least for us. We’ve got to have multiple parking lots and that has been broken since the end of last year at least. We opened that ticket on 12/29/10.
Sounds like asterisk was not told to generate a coredump, add the
following, then you can generate a backtrace:
dumpcore = yes
No, it just means that the coredump will not have information that is as useful
Sent from my iPhone
Paul Belanger writes:
The challenge with Asterisk and core dumps is that the Asterisk user
often does not have permissions to write to the directory it has as
current directory. By default, that is where the kernel writes the core
dump. You can change the directory by changing the kernel.core_pattern
sysctl, but make sure that you pick something which does not present a
It would be very convenient if Asterisk could be told to keep a specific
directory as current directory.
I presume that you are aware of the fact that it is impossible to prove
the absence of “bugs” in any piece of software….
You might not have detected them yet.
Furthermore behaviour that might have been coded on purpose, can be
considered “eroneously” some time later.
If you put it into production, test at least the functions that you are
going to use. There might (and probably will) problems in the code, but
as long as it does not bother you, so what?
And don’t stop testing after you put it into production: have a shadow
system (with representative configuration).
According to Murphy, side-effects will probably rise to the survice
after going into production….
End-users will come up with situations you never enticipated in your
See this thread here about Asterisk 1.8 – and Digium’s view on the matter.