Asterisk 1.8 LTS

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.

Hans Petter Selasky alerted the Asterisk developer community about a potential harmful pattern in Asterisk dialplans on February 9th.  His example is as follows:

exten => _X.,1,Dial(SIP/${EXTEN}@testsip)

He writes: “And if ${EXTEN} = “000@testsip&SIP/333” what turns out to happen then is similar to SQL injection 🙁 “He is exactly right. Many VoIP protocols, including IAX2 and SIP, have a very large allowed character set in the dialed extension, a character set that allows characters that are used as separators to the dial() and the queue() applications, as well as within the dialstring that these applications send to the channel drivers in Asterisk. A user can change the dial options and dial something we should not be able to dial in your system. This article describes the issue in more detail and gives you some help on how to avoid this causing trouble in your Asterisk server. (more…)

On my wishlist for 1.8 long-term-support release the #1 item is a new media negotiation framework for Asterisk.

The history – something to learn from

If we had integrated John Martin’s videocaps in time for release of 1.4 we now would have enjoyed four releases of an Asterisk with much better video support, instead of the broken support we have today. Integration of that code was denied because of plans of something greater and bigger, which we have discussed for years at many Astridevcons. Because of us denying this and other code,  outside-of-tree code has been around that fixes a lot of issues and the original Asterisk still lacks proper video support.There’s also a few codec negotation patches that has been around and maintained for years, one of the major ones being Maxim Sobolev’s patch.

What are the issues we need to solve?

There are a few main issues here:

  • Codecs: Codecs should not be handled as a bit, being turned on and off. Both audio and video codecs have attributes that we need to take care of properly
  • Call setup: When answering, the properties of the answer needs to be relayed to the calling channel, not just a control frame that says “somebody answered”.
  • Media streams: We should be prepared for multiple media streams, including multiple media streams of the same format

The new solution should be extensible, it should be easy to add both new codecs and properties.The solution has to be configurable. The way you want Asterisk to set up a bridge between two channels varies much. Some people prefer Asterisk doing transcoding some people want Asterisk to stay out of as much trouble as possible and just set up whatever is most simple. Other users just want to standardize all call legs to one type of phone, but have a different policy for other connections. There’s no one-solution-fits-all.

Asterisk needs a new media negotiation framework for continued success

We did write up a few documents on this a year ago at Astridevcon in Phoenix. I would really like to see some work on this. My personal feeling is that this is very important for the continued success of Asterisk in the marketplace. The amount of long-lived patches in this area that has been maintained for years shows that we have to do something (and that we sadly have ignored customer demand). The arrival of new codecs and new solutions, like video conferences with multiple audio and video channels, with text channels and possibly other types of channels (lika a binary channel for MSRP and digital ISDN) – all this tells us that we have to get there. (more…)