Asterisk news

I’ve worked with Asterisk many years. I started in 2002 when I was working with a service provider here in Sweden, then co-founded Astricon, started the Asterisk Bootcamp trainings and the dCAP. Many years of working with Asterisk, but almost always in combination with a SIP proxy (mainly SER/OpenSER) and in carrier networks.During the last weeks I have assisted a Swedish company installing an office PBX. This was a new experience for me. Of course, I’ve installed Asterisk for my own use and in the trainings, but this time it was a customer with very well-specified requirements. And I enjoyed every moment.

 Asterisk works very well in these enviroments. It’s almost as if it was built as a PBX. Right. Of course. Sorry. Asterisk is built for this. Exactly this. It’s just that in my work, I’ve used Asterisk as a PSTN gateway, conference server, voicemail server, billing server, session border controller, queue server, IVR server and much more. In those cases, we send a lot of traffic through Asterisk and push it to it’s limits. In the Office PBX market, Asterisk has more than enough power and shines. The flexibility is enormous and the things we can do with just a few lines of code is marvellous.

Working with all kinds of issues in the large scale environments, it’s always important to remember what Asterisk is built for and how well it fits that market. I had a lot of fun configuring this PBX, discovering new parts of Asterisk and trying to solve the challenges from the customer. Asterisk really stood up to this challenge and came out as a shining new powerful sports car, replacing the old PBX.

Of course, I came up with a few ideas that would make this easier. I reported them on – go there and check and report your ideas too!   

Asterisk 1.4 not only adds features to your PBX, it also adds enhanced voice quality for VoIP. The new and improved jitterbuffer implementation covers all RTP-based VoIP channels. Previoiusly, only the IAX2 channel driver had a jitter buffer implementation. (more…)

The Asterisk project has a very strict policy in regards to backwards compatibility. Unless we can’t find another solution, we’re not allowed to remove a function between releases. A configuration for Asterisk 2.4 should work in the next release. In order to be able to change functionality we warn users in one release and then remove the functionality in the coming release. So a configuration in 3.0 works in 3.2 but maybe not in 3.4.

This article tries to provide help with known problems with upgrading. Read on to learn how to avoid the traps! (more…)

Asterisk 1.4 delivers many new features. In regards to call state subscriptions, there are many news for you. Call state subscriptions are what makes the lamps blink on your phone when your collegue’s phone rings. In 1.4, you can make it blink based on activity in parking lots and meetme conferences as well. Read on! (more…)

Asterisk 1.4 introduces a new level of Jabber integration, developed by Matthew O’Gorman at Digium. The Asterisk Open Source PBX integrates with Jabber/XMPP in many ways. (more…)

Asterisk IdeasFor a long time, we have needed a platform for managing feature requests – things that the community or developers would like to see in Asterisk. We used to have a “feature request” category in the bug tracker, but there was no good way to handle them in the bug tracker and they where in the way for the work done by developers in the tracker. They ended up getting closed, only to be reachable by searching closed bug reports. Not a very good solution for brainstorms and good ideas.

The new site is basically a blog with comments and voting capability. You register on the site to be able to file a feature request. Other people may then add comments or vote for requests.

Hopefully, this will be a repository of ideas and a good discussion platform. Things will be stored and accessible. As usual, filing a feature request is not a guarantee that anything will happen. You still need to make sure developer resources are put to it somehow.

Please also remember that it’s not a support forum. You can’t get help in the idea repository. There are already mailing lists and forums in place for that.

Let’s try this out for a while and see if it’s a good tool that works for us. Register for an account on today!

Thanks for any feedback!


Happy New Year, Asterisk community!

During 2007 we accomplished a lot. We polished Asterisk 1.4 to a new state of readiness for production. We moved Asterisk 1.2 into no-maintenance mode, something I think we might have to reconsider after a discussion on the Asterisk-users mailing list. And we did not release anything new. Which is a good thing.

Why is that a good thing? Well, in an Open Source project you can choose between many different release strategies, depending on the software. Asterisk is a PBX. A PBX is in most cases something you don’t upgrade unless there’s a need to. We see that on the slow uptake everytime we release a new version of Asterisk. One year after the release of Asterisk 1.4, most of the installed base seems to run Asterisk 1.2. And they’re happy with it.

The problem is getting new features out there. We have a policy of not introducing new features to a released version of the software. That means we’re forcing people to upgrade to get new features – and new bugs. Would it be possible to create a new module interface so we can release various modules independently of the core? I don’t know, but that would create more complexity at the same time as it gives us a bit more flexibility for upgrades. At this point, 1.6 modules will not run in an 1.2 or 1.4 environment.

Anyway, I just wanted to write a note to say Happy New 2008! During this year, we hope to release a new version of Asterisk. During next year, you might be interested to put it into production. We developers just have to realize that it takes an awfully long time from idea to implementation in real life in the Open Source PBX market.

During the last week, I’ve been discussion upgrading Asterisk on the asterisk-user’s mailing list. I asked the community on what the problems was with upgrading to 1.4, asking for success stories as well as reasons not to upgrade. I’ve learned a lot from the feedback.As a developer, I spend too much time in the bug tracker, working with particular bugs, so I often wonder howon earth anyone can use this buggy platform for anything business-like…With that background, it really feelsgood to get reports on people successfully using our software and meetAsterisk users who just love the product and handle tons of callsevery hour with it.And as a developer, everything is of course more simple and you live inthe future, moving forward to new features, new functions all the timebasedon customer requirements or feature requests in the mailing list or thebug tracker…

Summary of the feedback

Now over to a summary of the feedback. I’m not going deeper intobugs reported, those will be handled separately.


For a lot of users there’s simply no reason toupgrade a PBX everytime we release a new Asterisk.Existing installations that work should not be touched unless there’s a very good reason to, like a new feature that makes business sense.Just upgrading for the cause of upgrading is a feature of the non-open software industry that gets a lot of revenue from upgrades.We developers has to accept that people appreciate our work, but decide not to upgrade every installation at every release. We might have to reconsider our support policy in the project, where wedevelopers abandoned 1.2 this summer. We might need another team that runs 1.2 support in the bug tracker.


Another issue is to make the upgrade much smoother. We can’t anticipate that people upgrade from 1.0 to 1.2 to 1.4 and readall the docs for every release. They can jump from 0.8 to 1.4. Or 1.0 to the future release of 1.6. We need to assist that and haven’t made a good effort in doing so.But even for upgrades from 1.2 to 1.4, we need to be more clear about changes that are required, especially for 1.2installations that already was upgraded from 1.0 and still use the 1.0 configuration syntax. They are going to havea broken configuration in 1.4 and this is the first time that happens in Asterisk.We need to make clear that Asterisk admins need to go through the log files in 1.2 and check all deprecation warnings. These needsto be fixed before even testing 1.4.


My personal goal would be to get the community to start using 1.4 for all new installations. We need to produce informationto help this upgrade path. It’s not about upgrading systems, since we’re talking about new installations. It’s about upgrading the Asterisk admins and installers – human beings.

The success stories reported to me personally and on the list indicates that 1.4 is indeed ready for production and it’s a great product.

With that, I’m now changing my focus from SIP invite states, RTP sessions and video formats to Christmas ham purchasing, baking Christmas bread (julvört) and decorating the Christmas tree. Of course, you understand that there’s an Asterisk asterisk on top of all those trees, right?After Christmas, I’m running the new Asterisk SIP Masterclass together with Daniel Mierla here in Stockholm. He’s one of the core OpenSER developers and it’s going to be a great class. I’m sure we will locate a set of new interesting bugs in svn trunk during that week. I’m really looking forward to that training. (Hint: We still have a few open seats… )Greetings from a dark and cold place in Sweden, without a decentamount of snow…Have a wonderful, merry and cheerful Christmas!/Olle

During one and a half year I’ve had a great oppurtunity to work with Asterisk development and evangelisation thanks to the Voop team, Thorsten Lockert, Gunnar Helliesen, Morten Reistad and the rest of the Voopers. They’ve paid part of my time so I could focus on long-term Asterisk issues and development, working in the bug tracker and starting the chan_sip3 (Codename Pineapple) project.

I think this sponsorship has made them the largest Asterisk corporate sponsor outside of the US. They have themselves contributed many patches, like the res_snmp module made by Thorsten and a number of fixes to the IAX2 channel.

Now, the contract is ending and I am looking for a new company to work with. If you are interested in sponsoring my work in the Asterisk project, making sure that I can dedicate part of my time to support the project, please contact me at oej (at) for an open discussion. The sponsorship has also included my participation in the SIP interoperability events, SIPit.

A huge thank you to the Voop team!


For many years, I’ve been working to remove the “type=user” and “type=friend” from chan_sip. In 1.4 you can in fact do everything you can do with a user with a peer. The only difference is the way we match incoming calls.

  • For users, we match the user object name with the From: username (without the domain).
  • For peers, we match on IP for incoming calls.

I’ve created a branch called “kill_the_user” that has no type=friend or type=user, only peers.alls are handled this way

  • First, we match on peer object name with the From username
  • Then we try to match on IP/Port
  • If we can’t match, we send to the context defined in the “general” section in sip.conf or to “default”.

If you can find any way this may give you problems, please inform me now. Otherwise, I’m goingto test this branch with all of you. I don’t foresee any problems going ahead with this in trunk.s compatibility, we will accept “type=friend” and “type=user” with a warning in 1.6,then remove it totally. Old configurations will still work. The longterm goal is to define new objects, please check the docs for Codename Pineapple objects,phone, service and trunk.For realtime, realtime users will not be used any more.I hope this will make chan_sip easier to understand and use. Feedback is appreciated!

« Previous PageNext Page »