This second installment as an ongoing project 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). 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.
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. 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 Required
Another laugh out loud moment is how many 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
SIP = Potential Resource Hog
As mentioned in Part 1, SIP can be a resource hog because it’s an app that puts strain mostly to hardware. 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 the 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)
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. 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 the Text editor I forgot its name off my head. A Mac running on a gig RAM and about 80 gigs HD can set up a sub 20 user environment. I have not done this, but I have spare Macs that can run OS X, and this could be a follow story when time warrants.
Redundancy is not documented, 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 pakets 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.
Lets focus on PCI cards. 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. 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.
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 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 sever in a totally another location, only catch is to ensure you have that documented in case of difficulty.
Part three coming soon with more scope on networking side of things.