Matt G. Watson

Migrating to Asterisk VoIP PBX - Part 2

Continuing on from part 1 of my Migrating to Asterisk VoIP PBX - Part 1 series off. In part 1 I talked about the problems we faced with our current PBXs and what the general plan was to fix it. In this part I’ll be discussing how we got our infrastructure prepared and began to take the idea from research to an implemented stage 1 of our plan.

I believe I failed in mention that in Part 1, as part of our research we needed additional software on top of just Asterisk. Management at our company wanted the system to be maintainable by the non-nerdy, mostly to just be able to do basic things, create extensions, change voicemail passwords, these kinds of things. Originally we outright said “sorry, thats not going to happen”, our initial plan was to write the entire Asterisk dialplan by hand, seeing as how Asterisk was new to use we knew this was going to be a challenge, but we were prepared to do it. Asterisk dialplans I consider to be a bit of an art form, while in a sense it is just another programming language, once you get into it you quickly realize it shares very little similarity to any programming language you already know. Asterisk does however offer an alternative to its regular configuration language that is a more programming-like language called Asterisk Extension Language (AEL). AEL however is considered experimental, that word alone was enough to make us shy away from it. I kept asking my friend Matt Gibson about Asterisk and how he managed it, he pointed me in the direction of FreePBX which is essentially web-based configuration utility for Asterisk that writes the majority of the configuration files for you, not to mention gives you a ton of features out of the box without having to write any dialplan by hand. Score 1 for management, they got the ability for the non-nerdy to manage parts of the system even after we said it wouldn’t happen!

At any rate, we began stage 1 with gathering all the equipment needed to run our head-office off our analog lines with hunt groups. I offered to loan some hardware which included, an entire PC that I had recently upgraded away from at home, my recently purchased Digium TDM400P, and my Linksys SPA2102 which would be used for attaching to fax machines.

This meant the organization had to buy, 2 FXO + 1 FXS modules for the TDM400P, and they needed a Digium TDM800P with 2 quad FXO modules for a total of 12 FXO and 1 FXS ports, we had 10 voice lines, and a fax line so we had one extra FXO port this cost about $800. They also needed a 48-port PoE switch to power the phones as we didn’t want to plug them into wall sockets, as its a lot easier to keep phones powered in a brown/blackout situation if they are all powered from the switch instead of individual AC adapters. Since we are a Dell shop, we bought a Dell 3548P this was just over $1000. We also had to buy about 25 more phones, this had a price tag of about $4200 from FLEWiD inc, who provided us with outstanding service, I’m still baffled by it, but we ordered 25 phones one day, they showed up the next morning around 10AM, all for the cost of $15 shipping… and thats total, not per-phone, how is that even possible? However, all this new equipment would have been completely useless if we had decided to scrape the project, with the exception of the new switch which we would of kept.

The TDM800P and TDM400P boards would be used to plug our current analog lines into which would allow us to test the system without the need of purchasing a rather expensive T1 connection, or getting our telephone provider involved at all.

Once we had all the hardware collected, it was time to get Asterisk and FreePBX up and running on our test system. This will seem very straight forward for the UNIX/Linux vetrens, but there is a great little guide available on VoIPphreak.ca. That guide however will not be dead on for everybody, it is designed for those running Ubuntu Linux, so you may need to adjust some things for your specific distribution. We happened to be doing this on Gentoo Linux, for those of you that may be running Gentoo, here are all the Gentoo specific things we needed to do

USE flags (not all of these are required, its just what we used, some of which are standards for us)

• dev-lang/php: apache2 berkdb bzip2 cgi cli crypt ctype curl exif ftp gd gdbm iconv json ldap mysql mysqli ncurses nls pcre posix readline session simplexml snmp soap sockets spell spl sqlite ssl sysvipc tidy tokenizer xml xmlreader xmlwriter xpm xsl zip zlib
• www-servers/apache: ssl

APACHE2_MPMS=”worker”

Edit /etc/php/apache2-php5/php.ini

• post_max_size = 20M
• upload_max_size = 20M
• allow_url_fopen = On
• allow_url_include = On

Edit /etc/php/cli-php5/php.ini (FreePBX also uses some crontabbed update scripts)

• allow_url_fopen = On
• allow_url_include = On

Once we had FreePBX up and running it was fairly smooth sailing with adding devices and users, FreePBX offers two modes for this “extensions” and “devicesandusers”, in extensions mode it basically means for every device there is a user mapped to it. You may not map the same user to multiple devices, and also your device id’s will be your extension number. In devicesandusers mode, devices and users are separate entities, you may have device # 300, 301, 302, but these are not dial-able extensions, they are simply device IDs, you then create users (extensions) that get mapped to these devices. This means you might have user 524 that rings on both device 300 and 301 simultaneously. We choose to use the later mode as it seemed more flexible for us.

Once we had a system working well purely internally, it was time to add some PSTN trunks to our system. What we ended up doing for this is going back into our wiring closet where our Nortel PBX was, essentially we ripped out the jumper wires on the punch-down block that connected the analog lines to the Nortel PBX, we then installed a series of RJ11 jacks on the wall, we would of gotten some RJ11 inserts for the punch down block, but this was only temporary afterall. So we wired up the RJ11 jacks, made some new jumper wires with RJ11 connectors on one end and punched them into the punch-down block where the lines fed into our Nortel PBX. The reason we did this is that it made it very easy for us to switch between the Nortel PBX and our new Asterisk PBX that was running on a PC sitting on the floor. It was just a matter of swapping the RJ11 cables between the systems, we intended on doing this switch several times which is why we didn’t just punch down new wires. All of our testing with the Asterisk PBX was to occur outside of our regular business hours, so at the end of the day we just went back, unplugged the RJ11s feeding the Nortel and plugged in Asterisk.

All was great.

Or well, it sort of was? We knew faxing was going to be a problem, as much as the majority of the people in our office dislike faxing, lets face it, its not going away any day soon. Faxing in VoIP telephone networks is troublesome at best. The reason for this is that Fax machines were made to run over analog lines, where latency does not vary, and bandwidth is guarenteed. This is because in the analog world, you essneitaly have a copper circuit between you and your remote party that is dedicated just for you… all 64kpbs of it. In the VoIP world, all of your audio streams are going over an IP network and competeing for network resources with all the other applications and computers running on your network. Parts of this can be solved with QoS, which I will talk about later in this series, however, QoS can’t always be controlled end-to-end. What if you need to fax using VoIP over the internet? Think your ISP is going to honor your QoS settings? If you said yes, I suggest you try again.

That all being said… believe it or not, but there are solutions to this problem. First and foremost, there is an ITU standard for Fax over IP (FoIP), this standard is called T.38. So why do I even bring it up as a problem? Well, T.38 support in current devices and software is not exactly fantastic. It has been around for awhile, but I don’t believe it has seen a lot of implementation, as VoIP is just starting to become more popular so people have not had the need to implement it. In a nutshell what T.38 does is decode all of the fax tones (T.30) into IP packets, which are then sent to your T.38 receiver, or T.38 gateway which then re-encodes the T.38 packets back into fax tones. T.38 handles all of the error correction, jitter, and latency problems that occur from your IP network. What we needed was a T.38 gateway, we wanted to be able to send a fax from a plain old fax machine over our VoIP network to our Asterisk server (gateway) which would then transmit the fax to the destination via the PSTN. Simple enough, but unfortunately not. Asterisk’s T.38 support is still in its infancy, it does not actually support the T.38 protocol, what it does do however, is support T.38 pass-thru. What this means is that it has just enough knowledge of the T.38 protocol to recognize a T.38 signal and send that signal on to something else that does understand T.38.

Fortunately for us, we were able to find some 3rd party modules for Asterisk to add T.38 support, these modules are a package called AttraFax made by a company called Attractel.

I got in contact with Attractel and obtained a 2-week demo license of AttraFax, the modules worked great, unfortunately they added significant cost to the new system, but we figured that for the amount of time it would save us figuring out an alternative solution, that AttraFax was the way to go, as it simply just worked out of the box. We did have some issues with it for a short time, but these problems got resolved by upgrading the firmware on the Linksys SPA2102 ATA that we were using to connect the fax machines to Asterisk, We were running firmware 5.1.6 and had endless problems with T.38, but once we upgraded to 5.2.3 it worked like a charm.

The next problem we faced, was how do we want to provision these phones? We certainly didn’t want to configure each one by hand, we knew we could configure by TFTP files, but again we didn’t want to create each config file by hand either. My co-worker and friend Arran, who was deeply involved in this project with me, came to the rescue by writing up a php script that would read the configuration data from the FreePBX MySQL database and create the config file for us. Since we had a standard issue phone essentially we didn’t have to worry about each phone needing different features. I’ll post the source code for these scripts at a later time.

The php script worked great, but I decided I wanted to automate the process as much as I could, basically what I mean by that is, I didn’t want to even run the configuration script myself, I wanted something else to run it for me. I wanted to be able to make config changes in the FreePBX interface, be able to reboot my phone and have those changes be reflected on my device. After a little bit of thinking, I decided to write a patch to the tftp-hpa server that we were using as our TFTPd server. tftp-hpa already has a regex pattern matching filter for re-writing file locations, this allows you to organize your tftp root directory nicely without having to clutter everything up in a single directory, since your tftp server might be used for many applications. The patch I created (source to be posted later) was an extension to the re-write engine. I added functionality to execute external programs if certain patterns were matched, all I now needed to do was in the rules file insert something like this:

x ^00085D /usr/local/bin/mkaastracfg

More on this to come in Part 3, where I’ll continue talking about infrastructure preparation and discuss more specific configuration parameters for each part our infrastructure.