BLF and FreePBX feature codes

One of the really cool things added to the latest version of FreePBX is support for Russell’s devstate backport for Asterisk 1.4. Today I decided to have a look at how it works, and I found it to be extremely simple and straightforward to set up. Obviously, you need to add the backport to asterisk. Luckily, that is extremely easy – just follow the directions in the readme.

Next, add the following line to amportal.conf (if it isn’t already there):


I was looking to see the status of my Follow-Me, so I needed to configure one of the BLF’s on my phone to reflect on the its status. To do that I needed to set the BLF to watch feature code that I would normally dial to activate the Follow-Me: *21200. I updated my 00000000.xml directory configuration file for my Polycom 650 as follows:

Call Forwarding

I then rebooted my phone, and like the magic that FreePBX is, I can now tell by a glance what the Follow-Me status is. Now if only setting up an orb would be as simple!

Moshe Brevda, FreePBX Development Team
lazytt – FreePBX forums
hi365 – IRC

An introduction and an announcement

Hi, my name is Mikael Carlsson and this is my first blog entry here on FreePBX.

I decided in December 2007 that I would translate FreePBX to Swedish as we were using it at our company and wanted some of the modules in Swedish. After reading up on the matter I filed a Feature Request #2571 that proposed a change in how translation should work for FreePBX as I was not that happy with the solution that existed. I also posted this in the wiki: NewLanguageSystem. There was some interesting discussion about the matter but it kind of dried out. I then decided to skip the proposal and go on with the translation as instructed on the wiki: OldPageI18n (note that this page is now obsolete).

Oh boy, that was a task, there were a lot of text strings that did not translate and there were a lot of spelling errors. I started to post the spelling errors as tickets and got back a plea from one of the developers that I should post the spelling errors as a diff file. I started to do that, and quite frankly, there were many spelling errors, so I posted about 15 tickets and as a result of that I got an e-mail from Philippe that asked me if I was willing to check in the changes to svn by myself. A couple of emails later I got access to svn so that I could commit my own changes. My status on the forum went from tadpole to Contributor. And I started to send in my fixed spelling errors.

I then discovered that there were a lot of places in the FreePBX code that did not enclosed text string with the proper _() enclosures. I asked Philippe if it was OK to fix that and I got a go for it. My status went from Contributor to Developer. So, over the next couple of months I fixed spelling errors, proposed changes in the code and provided some bug fixing as well. One of the weakest parts of the localization was that for us to fix a spelling error in a module we had to publish a new version of that module.
Philippe then created the module fw_langpacks. It is a cleaver module that pack together all languages files for FreePBX and distribute those as one module. No more worries about publishing new versions for modules after spelling errors anymore. Next problem that we discovered was that there were many places where FreePBX could not translate properly because of its modular nature and the way that one module can hook into other modules.
After relentless testing and collaboration with other FreePBX developers on this issue, we finally have the ability for a module to provide all its required translations from navigation menus used by the FreePBX framework to hooks inserted in other modules. For those translators who may have struggled with the incomplete solutions of FreePBX in the past, I encourage you to have another look now.

After over 6 months of translation, bug fixes, spell checking, text string enclosures and endless questioning in the freepbx-dev IRC-channel I finally did it, I submitted the change in FreePBX language selector so that Svenska was a language choice [url=]6725[/url]. It was a great moment for me.

We were finally there. We had fixed (the FreePBX crew and I) so that FreePBX can be translated in full to an another language. In the [url=]roadmap[/url] the following text says it all: [b]Looks like we have a winner! I18n.[/b]

I then decided to clean up the procedures so that other translators could benefit from our work. I submitted a feature request #3175 and started to work on that. It is in version 2.5, if you look at your modules/i18n directories you will find a template file for translations. I then updated the wiki to reflect this change [url=]I18n[/url].

And now the announcement (or should I say Plea?)

[b]We need more translators![/b]

The remaining languages currently defined in FreePBX need an overhaul: French, German, Italian, Spanish, Portuguese, Hebrew, and Hungarian.

If you feel like helping out, please do so. All help is appreciated.

Russian translations are made by Alexander Kozyrev and he has done a wonderful job with that. We have also one person, lucas, submitting Spanish translations. But we need more people to help us with the languages. Or if you like to do a language not listed, please feel free to do that. Read on the wiki I18n for the guidelines.

Please do not hesitate to contact me if you have any questions on how to do the work. I am here for you.

[b]Mikael Carlsson[/b]

AsteriskNOW goes FreePBX and a Great Time at Digium


It looks like our most recent Open Telephony Training Seminar at Digium’s Headquarters was a success beyond our wildest dreams! Digium was so impressed with FreePBX, our community (as represented by the class attendees), the great attitude of everyone (who else has participants set up camp with their RV in the Digium parking lot), and the project as a whole that they went off and created AstriskNOWTMwhile I was on the plane returning from Huntsville!

I must admit the announcement was not a complete surprise, having used our captive audience last week as a test bed for the new AsteriskNOW distribution which went very smoothly. If you are looking for a clean ISO with out a lot of extra fluff, this is an excellent option to consider. Although it is still in beta with a few minor known issues that are being addressed, I expect it to come out strong.

The most recent OTTS training was well received and our class was the first to get the revised material focusing on the great FreePBX 2.5 release that went final last month. We also heard much positive feedback about the quality time spent with Mark Spencer, Danny Windham and other Digium Asterisk developers during the week and over dinner. (And I didn’t hear any complaints from Tony who was kidnapped by Mark for a birds eye view of Huntsville in Mark’s Diamond DA40XLS!)

With their great training facility, the wonderful hospitality everyone received and the overall exceptional experience, how could we not plan on coming back soon. So if you couldn’t make it last week, here’s your next chance:

January 20th-23rd, 2009, again in Huntsville, AL

If you couldn’t attend this last opportunity or want to be one of the first to come to the next AsteriskNOW/FreePBX training, then sign up early while we are still offering an un-advertised EARLYBIRD discount of $300 until the end of this month.

For now, we hope to see you in Huntsville but it’s time to get back to work. One of our developers has done some nice improvements embedding the audio player into the User Portal (Recording Interface / ARI – no more pop-up!) so we are off to get that into a short lived release candidate for that component so we can get it out to you quickly. If you would like to help accelerate that activity, you can aways "press here":


Philippe – On Behalf of the FreePBX Team!

Miscellaneous/Custom application/extensions: How to extend FreePBX with custom dialplan (part 2 of 2)

In part 1, we were discussing the basics of how the Asterisk dialplan works. To recap: asterisk is made up of contexts, which can in turn include more context, creating the whole dialplan. FreePBX takes advantage of this structure by creating a lot of contexts and then included these in each other. Until now, the easiest way to include your own custom dialplan was to put it in one of custom context that FreePBX intentionally leaves blank for the purpose of customization. Now (actually since version 2.3) FreePBX includes a module to make the process easier, simpler and cleaner.

To include your own dialplan in the call flow, we use a combination of modules. First, we need to tell FreePBX where in our dialplan we would like to point to. To do this, we set up a Custom Destination (from the tools tab) with the custom description pointing to out custom dialplan in the format of context, extension, priority. To refer back to our previous example, we would set the custom destination to: play-monkeys,66,1. We will also add a Description so that we can easily remember what this dialplan refers to. Lets call it play-monkeys. Then click submit.
Next, we need to create a Miscellaneous Application. The Misc Application module allows us to set up an extension (remember, in Asterisk an extension is somewhere in the dialplan that you can call – not necessarily a phone) that can point to anywhere. For example, if you want your users to be able to call an IVR which is usually only heard by inbound callers, you can set a feature code to call the IVR every time the feature code is dialed. Now we will set up a feature code to call out custom context: Click Misc Application from the setup tab, and enter a feature code, say 11234. Next Enter a description, say call monkeys. Finally, chose our custom Application form the Destination menu Custom Application: play-monkeys and finally click submit.
Now your all set! Reload FreePBX by clicking the orange bar, and call 11234 – you should hear the tt-monkeys file being played back!
There is one more thing to keep in mind. Sometimes, for whatever reason, you don’t want to call your custom dialplan directly from FreePBX. Nevertheless, it is important to make sure that you don’t accidentally assign a duplicate extension in both FreePBX and the dialplan. Being that FreePBX automatically picks a lot of the extensions it assigns, we need to let it know which extensions NOT to use. To do that, we use the
Custom Extension module (tools tab), and we enter the extension number we want to prevent FreePBX from using. This will prevent FreePBX from chosing an extension that you already assigned manually in the dialplan.
That’s all. Be sure to check back again next week for a tip on how to list all of the contexts and their includes from the dialplan!
Moshe Brevda, FreePBX Development Team
lazytt – FreePBX forums
hi365 – IRC

Miscellaneous/Custom application/extensions: How to extend FreePBX with custom dialplan (part 1 of 2)

FreePBX was primarily designed to be a simple and easy to tool for programming asterisk dialplan and call flow. In the name of simplicity, however, it is sometimes necessary to sacrifice advanced features and overly complex ways of doing things. FreePBX takes a great middle ground in providing the best of both worlds: on one hand, an extremely powerful yet intuitive and simple GUI, and on the other hand a really neat way to seamlessly extend the gui into ‘raw’ dialplan. This is done using a combination of the Custom and Miscellaneous modules.

First, a small refresher on Asterisk Dialplan. Every asterisk instruction is composed of four parts:
  • Context
  • Extension
  • Priority and
  • Application

For example:


exten => 66,1,Playback(tt-monkeys)

In this example, when a call hits extension 66, priority 1 in context play-monkeys asterisk will Playback the tt-monkeys voice prompt. Additionally, Asterisk also includes the ability to include one (or more) contexts inside another using the (believe it or not…) include command, for example:


exten => stuff here

include some-other-context

FreePBX takes advantage of the include feature to keep its dialplan simple and clean by breaking up the dialplan in to smaller contexts. The context FreePBX uses for its call routing is the from-internal context. from-internal itself is pretty much a blank context – accept for two includes. You can see it here:


include => from-internal-xfer

include => bad-number

from-internal-xfer includes (amongst others) from-internal-additional and from-internal-custom. from-internal-additional is also pretty sparse – except for some more includes of many, many smaller context, corresponding to the entire FreePBX generated dialplan. from-internal-custom is always included – and always empty – so that you can use it as you’d like. Simply start a new context in /etc/asterisk/extensions_custom.conf and add your dialplan there. So to include our play-monkeys context in the FreePBX generated context we would add the following to /etc/asterisk/extensions_custom.conf:


include => play-monkeys

exten => 66,1,Playback(tt-monkeys)

followed by a dialplan reload (asterisk -rx "dialplan reload" or asterisk -rx "extensions reload" if your on asterisk 1.2). That’s all! Now pick up an extension and dial 66. You should hear the tt-monkeys file being played back.
While this method is really simple, its got its drawbacks: If you were to include some code with, say, extension 66, and then you would set up a phone at extension 66 in FreePBX – what would happen when you dial 66?
That’s right, asterisk would be kinda confused: it wouldn’t know which ’66’ to call (actually it would pick one of them – but which is another story). In order to prevent such a situation, FreePBX rigorously protects the dialplan from having a double entry. You can’t, ever, have two extension with the same extension number (try it!). You also can’t have other ‘destinations’ (which are also called extension in asterisk dialplan language) such as ring groups or queues with the same extension number as another extension.

to be continued…


Moshe Brevda, FreePBX Development Team
lazytt – FreePBX forums
hi365 – IRC