2011 January

January 2011

Building services in Asterisk is about combining a lot of small services into larger building blocks. The Asterisk platform provides you with a large set of functions, like calling out, answering, recording, playing prompts and listening for DTMF. In combination with simple logic control statements – much like any other programming language, you can use these to build complex services. Asterisk very much follow the design principles behind the UNIX operating system – small building blocks combined with a script language may build very complex larger services.

The dial plan language gets more powerful for every release

During the years, the possibilities in the dialplan have been expanded. The language have gotten a lot of new constructs and both functions and applications.  I can admit that the language is not the best of languages, but it performs the job. Compared with Asterisk 1.0 the need for using an external language in AGI is much lower with Asterisk 1.8. Thew is one big roadblock that breaks the design Рvoicemail.

Asterisk Voicemail is a large monolithic roadblock

The Asterisk voicemail application does not follow this design. It has built-in menus you can not change. It has built-in assumptions on how you want to handle your voicemail that you can not change. It has built-in accounts that is not very adaptable or easy to fit in with your LDAP architecture.Many people have private versions of voicemail – either hardcoded changes to the app_voicemail.c source code or something they wrote in the dial plan. A few years ago I started my own voicemail system for a customer who just needed a small voicemail-to-email solution – mini voicemail. It was a bad name, it should have been named voicemailblocks.

VM-blocks – the tools you need to build voicemail solutions

The idea was to build a series of voicemail building blocks that anyone could use to build larger customized voicemail solutions. I still think it is a good idea. After I developed the original code, channel data stores was added to Asterisk, which should make it much more easy to build the rest of these blocks. A vm-block channel data store can keep all the data about a voicemail account in memory that can be shared by the different dial plan applications.I hope that someone in the Asterisk community agrees with these ideas and continue coding on this. The first blocks are part of Asterisk 1.8. Let’s hope we get a more complete system for 1.10. If you are interested, I am open for discussion so we can agree on the blocks we need.

Asterisk was originally built as a stand-alone system, a single central point for all telephony communication. In short, a PBX. Nowadays, the Asterisk Open Source telephony server, is used in many ways – many of them not really being PBXs. All kinds of applications are being powered by Asterisk.While building applications with Asterisk, you soon realize that you’re limited to that single server. It’s hard to scale and one limiting factor is that the call state is being held in one server. Many services depend on call states – if an agent in a call center is busy, you need to find an available agent. If a trunk to the PSTN is in use, you might want to find another way out. Call states are important.Of course, the Asterisk project is now working on the long term solution, the Asterisk SCF and the applications that will be built using this framework. But that will take some time. Meanwhile, the Asterisk PBX team has been working on a few ways to distribute the call states between a group of servers. This article will describe a few of the different architectures being worked on. (more…)

IPv6 has lead to many bad user experiences in the web world, something we in the SIP community needs to learn from and avoid. Many problems come from the idea about dual stacks. For softphones, dual stack will be a reality, for edge servers it is a must-have but for hard phones it might not be a requirement at all. We need to develop a best current practice. While the web browser can take a few seconds to retry connections, doing that for a phone call might be a disaster. Especially if it happens for every phone call.


You are drafted for my IPv6 SIP task force! Here’s our action points:

  • Review IETF documents on SIP IPv6 ¬†migration. Are all depending on all devices having dual stack? If so, does it really work?
  • Test IPv6-only solutions. Do they work? Is it possible to use Asterisk or Kamailio for reaching IPv4 SIP devices?
  • Test DNS SRV records. Are they usable to indicate your preference for IPv6 or IPv4 calls to your domain? Will devices support it?
  • Check SIP service providers – do they support IPv6 today?
  • Check Open Source solutions – is the IPv6 support complete? Does it work both in dual stack and single IPv6 stack mode?
  • Check phone manufacturers – does their products support IPv6?

Are there other questions to sort out? Is so, let me know. And let’s make 2011 the year when the SIP world embraced IPv6!