Mini Asterisk GUI

For the last 5 weeks I have been hacking away part time on Mini Asterisk – a new GUI for Asterisk. Here is the on line demo, hover you mouse over the fields for instructions and read the FAQ.

Several factors came together to build enough motivation to start this project:

  1. The ease-of-use discussions we have been having with the Village Telco project. Just how easy can we make Asterisk to set up?
  2. In particular the 10-click-install meme in this Village Telco blog post.
  3. Making the IP0X embedded Asterisk products easier to use. Asterisk is really really hard for people who don’t know Asterisk. Even with the current batch of Asterisk Now based GUIs on the IP0X they are way harder to set up than say a router, especially if you don’t know Asterisk already. The promise of the easy to use Asterisk “appliance” hasn’t been delivered.

I also wanted to play with some ideas like:

  1. Lower the technical bar as far as possible. Can my wife and kids set up an Asterisk based phone system?
  2. Pre-configure everything in the name of swift set-up. In the current version on Mini Asterisk you can’t even choose the extension number of your phone – it’s pre-configured. For new users too many choices can be a bad thing.
  3. For more advanced features allow and encourage access to the conf files. Many of the problems with Asterisk GUIs occur because they try to control every Asterisk feature available. This leads to zillion-option GUI screens that are overwhelming for newbies, and problems when the conf files and the GUI don’t play together. Instead I have tried to make a really simple GUI that has very basic features. For anything advanced then edit the conf files (which the more advanced users probably know anyway). The GUI has been carefully written to play nicely with conf files, mixing the GUI and direct conf file editing is encouraged.
  4. The Asterisk programming model is ignored by Mini Asterisk. There is no mention of dial plans, or Zap/1 or other arcane knowledge. Instead we talk of Phones and Phone Lines.

In an ideal world I would have used something like FreePBX but that is just a bit too heavy to run on an IP0X. I tried a Blackfin FreePBX port a few years ago with some success but it hasn’t progressed since then.

For Mini-Asterisk I started out trying to use the built in Asterisk AJAX/Astman system but after a few days got stuck when multiple events were being returned for one call. So I wimped out and used plain old CGI technology. Yep, a bunch of shell script, HTML, and just a little Perl for grokking conf files. I actually enjoyed writing a web app using shell script. Sick and twisted I know. Much to my surprise I could build GUI screens really quickly using shell script. Performance isn’t an issue, as it’s only single user.

The only time I got stuck was when I had to come up with a regular expression. This is like coding in Klingon, so I would spend 30 minutes on the command line pressing up-arrow, mess with a few characters, up-arrow try again etc. But strangely rewarding when they finally work.

Is this a worthwhile addition to the Asterisk space or I am wasting my time? Not sure, but I’ll be shipping Mini Asterisk on the IP0X from now on so lets see how it goes. It also runs on x86 for those people who want a simple, lightweight GUI to run a few IP phones and make a few VOIP calls without installing an ISO. Please give Mini Asterisk a try and tell me what you think.


Thanks Hadley and Joel for helping with design and testing of the GUI.


On line Mini Asterisk demo. Hover your mouse over the fields for instructions and read the FAQ.
Mini Asterisk Page.
Browse Mini Asterisk source code

6 thoughts on “Mini Asterisk GUI”

  1. Great project, David!
    And concept looks really nice for me. Little bit better web-design and it’ll be a winner. The only thing slightly annoying is all those popups, which sometimes obscure your view. As an idea – could you display help not in a popup, but in a small area on a page, somewhere on the left or right side of a screen?

  2. Thanks Alex. Yes I would appreciate some help with the design side. Interesting point about the pop ups, I’ll think about that. In normal use of the GUI, they don’t appear as people are mainly pressing menu buttons.

  3. Nice, but the password handling is a tad too simplistic 😉 It is normally done by creating a session cookie (hash of user/pass/ip/timestamp) and checking that on the other pages rather than the trivially exploited loggedin=1.

    For slightly less bare bone shell CGI scripts, you might want to take a look at haserl, as it handles all the CGI stuff and is tiny (~20K)-

  4. Thanks Peter yes the security model is far too simple, I will look into your suggestion to the next revision. A session cookie means I would need to store it on the server, in some sort of database. I am not sure how to implement that. Also need to work out how to debug scripts from the command line with such a security model. The current model makes testing very easy.

  5. > A session cookie means I would need to store it on the server

    Why? You just need to be able to verify it.

    E.G. cookie = hash(user + pass + ip + timestamp), where timestamp is the current time on the server truncated to 15 mins (or how long you want your timeout to be). Set this cookie at the login page and just verify it on all other pages. You can even update it if the timestamp changes so the user doesn’t time out as long as they click on links.

    For debugging you could perhaps just print the correct key to stderr so you can easily see what it expects.

Comments are closed.