Matt G. Watson

Just another geek
Add to Technorati Favorites
May 13th, 2008

Migrating to Asterisk VoIP PBX - Part 1

This first series of articles will be a recount of my experience recently with a VoIP project that we implemented over the last 6 months where I work. I have taken a phone-system consolidation project from idea to research to testing to a completed project. Part 1 will focus mainly on our existing infrastructure and what the plan was.

We had tried to do this a year previous, but relied on outside companies to propose something to us, my opinion is that they didn’t do a great job selling their idea and really left it up to us to find the benefits. Unfortunately we failed to find enough benefits to outweigh the costs. This project was always in the back of my head and a year after that and I still wanted to do it. One day a co-worker said to me”Why can’t we transfer calls between offices?”. My reply was “Great question! You should go ask <our Manager of Finance>”, she was the one that was part of the original try at this, and ultimately the one that decided we couldn’t afford it then. My biggest problem with the system was the lack of ability to transfer between offices, being that I work at head office, I always overheard phone calls to our receptionist where people were looking for our staff members that worked for another program that did not operate out of our building, but operated out of the other 3. We would have to give the person the phone number for that program’s main office, and then that receptionist might end up telling them that person is in a different office and have to ask them yet again to hang up and call another number… we thought this was horrible client service and wanted to fix it.

After that co-worker said this to me, I began doing some research, a friend Matt Gibson had talked to me off and on over the past year or two about the Asterisk open-source PBX, however I didn’t really know a lot about it at the time. I began asking him a lot of question about it and eventually decided that it sounded perfect for us. I started doing a lot of research on my own time and did some number crunching to find out what it would cost to implement, and more importantly, how in the long run it would save us approximately $7000 per year. To a non-profit that is primarily funded by offering various government programs, that can be a big chunk of change. I poured a lot of heart and soul into this project, I truly believed it would be great. After I had crunched my numbers, I approached our Manager of Finance again with the project and said “What would you say if I told you the telephone system project would cost you $25,000 but it would save you $7000/year… would you be interested?”

Fortunately for me, she was. I knew saving $7000/year would be hard to say ‘no’ to, but I also knew that having our organization put a $25,000 investment into it could also very easily be a ‘no’.

Now a little bit about the technology we have and decided to use for this project. While we may be a relatively small charity, we have relatively high-tech stuff for our size, we are quite fortunate in that regard. You may ask what we are doing with such a network setup, well the answer is that we also operate some very technology/internet-intensive programs. Our organization operates out of 5 locations, one of which is our data centre and acts as our network hub, see our network diagram.

I’ve blurred out any public IP addresses or company names. A bit of an explanation is probably required. The far left of the map is a site we call NCGC1, this site is our data centre which a local college kindly offers us space & electricity for in one of their server rooms, we have no permanent on-site staff here, just lots of servers. The far right of the map is our 4 locations that our staff work out of, THO1, STC1, WELL1, NF1 - THO1 being our head office. The cloud in the middle is our network provider. Essentially each staff site has a TLS (Transparent LAN Service) connection to our data centre which has a pair of Cisco PIX 515e firewalls as our main firewall, all internet or inter-office traffic flows through these firewalls. Each site also has a router, these are all Linux-based routers, specifically they are running Vyatta VC4, though at the time they were running earlier versions of Vyatta, the Dell 3548P switches were also not there at the beginning of this project, and lastly the Fibre connection to STC1 was an ADSL connection.

At the time, our voice systems consisted of having standard analog lines with hunt groups, we had 1 Nortel PBX, and 2 Lucent Partner ACS systems, all of which were very old, they lacked features, but most importantly to me, they were not integrated.

The plan was more or less simple, run Asterisk on a server, purchase new IP handsets for all of our staff, replace some switches with Power over Ethernet switches, and preform a network upgrade in the STC1 site (this was wanted for other reasons too).

Since I was new to VoIP in general, and especially new to Asterisk, I purchased (personally) a Digium TDM400P Analog PSTN interface card and an Aastra 480i IP phone to familiarize myself with Asterisk.

Once I felt good with it, I came back to my employer and said “yes, I think this is going to work, but I need some money to do some more research”, this research mainly was that I needed more phones, and I wasn’t willing to shell out more of my own money on phones that I might not want to keep myself. I got the OK to purchase a few more phones, these were an Aastra 9133i, another Aastra 480i, and an Aastra 57i with 560M sidecar. The idea was to use the 9133i’s as our standard-issue staff phone, the 480i’s would be the power user phones, and the 57i+560M would be for receptionists. All my research went great once I had some more devices to play with.

Once I got the OK to move forward with the project we planned out a 2-stage implementation plan. Stage 1 we considered a “beta test”, we would implement the new system at our head office only (where the Nortel PBX was) and would not be integrated in any other buildings. It was made clear that they needed to be willing to throw away this money if it didn’t work out. We could easily just plug our Nortel back in and that would be the end of the project.

Stage 2, obviously, is where we take the system organization-wide.

In Part 2 of this series, I’ll go over our implementation of Stage 1, the challenges we faced, and how we overcame them.

Leave a Reply