This page will be on the basics and general concept of implementing Basic IP voice services though the Asterisk system, I’m going to walk through the keys to reliability. This is mostly a hardware discussion.
Single Vendor, Common Model = Limited Glitches
In any moderate to heavy VOIP setup, it should be recommended you stick to a single vendor/models. Try different sets to see what works and what doesn’t work. I personally lothe Polycom outside of their analog offerings. I don’t like their design (hate how the hand/headset cables just sit out (pleases them IT layabouts I bet), the User Interface is laughable, and administratively it’s nightmare. And while they are cheaper than Cisco, its essentially a Cisco clone because the phones have lots of limitations in my opinion.
Nortel might be a decent solution if you want to try using UNISTIM, not sure if that would be a CPU intensive process or not. I’ve read that Avaya IP Phones (outside the proprietary 4606/12/24/30 models) can run behind an Asterisk if you have it on SIP mode, but had limited success with my attempts except I got a 4602 to work, then after a couple of network outages the phone was unable to register on the Asterisk. It currently serves as a wallflower.
Cisco would be a hit or miss, and would be a miss you can’t decode the code-heavy setup of Cisco. There are third party plugins like chan_skinny, but again it can be time consuming. Also if you love Cisco, I recommend using the Skinny protocol. Why? You have wideband audio, especially for the speakerphone (SIP is just as bad as analog voice), the sidecars do not work on SIP (maybe in newer releases, not sure) and other advantages than the trial and error setup of SIP.
Labs or hobbyist with one desk having a Cisco another one running Grandstream and the bedroom having Avaya is one thing. Trying to run them in some production or a business where voice is critical can be actually be unprofessional. It could break a uniform look and managing them can be horrific.
DHCP services vary model to model. As mentioned in the first part, I’m using Mitel in this project, which requires Mitel-specific DHCP options. Some IP phones limit the use of TFTP as its becoming more antiquated due its insecurity. Mitel, and Avaya have the option to use HTTPS or HTTP server, Cisco still is stubborn with TFTP, even when its now deemed an unsafe solution. Make reference of that. Using a Windows Server with DHCP is strongly recommended, if you have access to one. Various vendors have various “classes” and ways to get to DHCP. DHCP servers also have options to bind IP addresses or direct them to appropriate TFTP servers by it’s MAC address. Routers, especially SOHO and mid sized routers will not cut it. OS X or Linux does not have an easy way to point and click to DHCP settings specific to devices or a group of them.
Using DHCP servers helps phones reach to specific TFTP servers and request certain settings and require less manual programming on the sets themselves. Avaya is easier for keypad administration, while Mitel is a little odd. Some phones Avaya’s IP Telephones/Deskphones commonly requires using a .txt file to receive settings, known as the 46xxsettings.txt (referring to the first generation IP phones that Avaya made.) Cisco has very pretentious ways of deploying if you don’t know how to configure a Cisco phone outside the protected gatekeeper, the CallManager. Unless you know UNIX and how to code, and write foreign files, then this can be for you.
Networking Skills Recommended, but not Required
As mentioned before, its easy to laugh out loud when people who set these things up probably for a bragging purpose often have to learn new things like TCP/IP, and other services that don’t get mentioned on the sites of the distros. In order to have a happy and healthy life running VOIP/IPT in production, you will need to learn basic to moderate understanding of how QOS (quality of service) and COS (class of service) as well as VLAN. I don’t have the time to discuss all of these, so it’s best to at least do other research online and with books on these subjects. A good practice is to have it run on its own network and have one gateway reach out to the data network so you can daisy chain your IP telsets with your PCs.
SIP = Potential Resource Hog
As mentioned in Part 2, SIP can be a resource hog because it’s an app that puts strain mostly to hardware, like the server. Ensure you have your Asterisk has enough resources to handle the volume of calls. Again if its a lab or at home and all you need is 2 concurrent calls you might get away with, but if you are an enterprise (over 200 terminals) – you’ll need to do homework and proper planning. SIP doesn’t tie up a network if properly planned, but can cause problems on the “switching” end (in this case it would be the server running it.)
What can happen? The phone might get locked up for about 10 seconds getting a call to go into place (this can be a serious quality problem.) Sometimes you might go on and off hook because one looses patience getting a call appearance to fire up. (File this under I Press the Windows Key and it does nothing, and the Start Menu goes off and on for 20 seconds.)
Also ensure the PC has enough RAM and hard drive space to run the application, bears repeating.
Single PC for a Single Application (Separate Server for an Asterisk)
Servers Serve, Workstations Work
Novell Circa 1998, NetWare 5.1 documentation
As mentioned already, this can’t be stressed enough! There are going to be whack jobs who think they can run their PBX on a same system that does file sharing or even worse a domain server. This is what really drives me nuts with IT guys who want everything open, then they start bitching why there are so many attacks on their networks!
After installing the Asterisk distro, typically after logging into the system via the CLI prompt, type SETUP and it should take you into a Linux screen setting up TCP/IP, firewall and DNS settings. Check the only things like IP, DNS, TFTP, FTP, DHCP, HTTP, and HTTPS. Anything not relevant for the use of IP Telephony, TURN OFF!
Macs running a minimum of Mac OS X Tiger can possibly run Asterisk. (as of 2015, I’m trying to do this on an old Blue and White Power Mac G3.) If you are someone who is a visual user, or needs a graphical orientation of Asterisk, I would recommend this. One catch. You should again run this Mac that will be dedicated to do telephony and remove all non-essential apps (except for the ones in the Utilities folder and apps like TextEdit. Server edition probably would be the safest bet. A Mac running on a gig RAM and about 80 gigs HD can set up a sub 20 user environment. I am working on this and right now its not as easy as the Asterisk will crash within 10 minutes. The web console doesn’t work and SIP traffic can’t talk to the system even when the firewall enables this traffic.
Redundancy is not documented that well, at least from what I can read. I do not know how to create an Asterisk as a redundant server, therefore I can’t document this at this moment. Redundancy is important to any software based PBX system. Avaya’s Communication Manger and Cisco’s Unified Call Manager as well as major players offer (and some require) at least one or more redundant servers. If there is a solution, I’ll post it
Separate Servers for Asterisk Services/Applications
Another “gotcha” (at least with my experience) is because the Asterisk systems are so integrated, if you got a single PC or server, it may not be able to handle all the applications as one. Again the guy who invented Asterisk was allegedly modeling a “PBX” from ether a Norstar or a Merlin Magix, which runs a virtual “PBX mode”. Both systems support up to 200 ports, and again you’d be very lucky to run at least 100 without problems on a lower spec PC. Again this may bring up problems if you do not have enough resources to run on a single box.
Gateways typically take the packet (IP) data and convert it to another medium. There are data gateways that convert data to a DSL medium, to cable (coax), T1, etc. In VOIP there are similar gateways that converts the voice packets into another medium, that can be for analog trunking, T1, PRI or even to another PBX. For this exercise, I will be using analog called Foreign Exchange Office or FXO.
Now on PCI cards. Asterisk’s publisher sells PCI cards to connect the Asterisk to the outside world. This may work for some as its all integrated, not so for others. A single T1 card might work, or one or two PCI cards for Plain Ol Telephones (POT) or analog trunking. Some VOIP setups can be strictly analog for phones and one IP phone for attendants, and the trunking could be VOIP based. Before setting the foundation for trunking or analog phones or other gateways start planning that first. Typically most workstation class PCs have up to 6 PCI slots, most cases just about 3 or 4. Another “gotcha” moment would be in this case if you are wanting to do a single box setup and all the hardware in one box plus everything else. This can put the system into high stress and cause the system to crash or cause calls to hang or not be answered.
Now if that is the case, I suggest looking into small appliances like FXO and FXS gateways. Just like a router or a wireless access point (WAP), these little to big guys won’t be chained into the PC’s logic board and are more mobile. You can have your communications server in the data center and have your analog hookups in the area they are most needed in and then plug them into the LAN via an Ethernet cable. This reduces the cost to rewire or add wiring from the remote wiring closets to reroute to the data center or vice versa and reducing the need for the PC to handle gateways so it can focus on routing calls, or taking voice mail.
H323 gateways is another option, and if you set it up right, it can be more reliable than SIP if you struggle with administering SIP. Yes, SIP can be tricky.
In my case, I used a Cisco Router (tried it on an IP Office before the thing died) with SIP to talk from the Asterisk to the Cisco router which then would dial the call out if needed. This is an ongoing project that I was looking to mess around with, but had been busy with other projects.
Gateways – Location Dependent
It’s important to understand gateways need to be in locations where they are needed the most. Marketing materials show the server next to the gateways, and while some environments may work that way, don’t believe the PR entirely – another IT mistake! Gateways were once called a processor network or port network in the pre-IP days. PNs were located in wiring closets where the connection from the switches to the desk or wall phones were located. If you had remote sites in a campus environment or if you are in a hi rise building, you’d have these things in different parts of the building or land. Before the transition to IP most phones could travel up to 3,000 feet (you miss those good ol’ TDM days?)
Physical environments are not virtual, IP is. You can have gateways in any part of a building and have the server in a totally another location, only catch is to ensure you have that documented in case of difficulty.
Call for Help
Proper gateways is also important for e911. It also doesn’t hurt to pay $35x/month (US) for basic copper wire telephone service (that’s if you still got one of those in your area.) You can program an analog gateway and set it up so one if someone needs to call 911, the system will dial out to that gateway and then supply additional information for the calltaker. You could do this with VOIP, but with the overbearing government (thanks to Fletch at Avaya preaching such legal movements) this could be risky and cost your company big. Take the least destructive route and get an analog line and gateway in each building and route 911 calls to those gateways.