2007 December

December 2007

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 Asterisk.org 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) edvina.net 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!