I’ll be doing a series on Implementing Asterisk. This subject is about VOIP*, to some is sexy in terms of lower costs and high benefits like click to dial, Active Directory Implementation, etc. etc. VOIP is really not a sexy subject, especially when implementing and set up the idea of reliability, security and resiliency. This could be the case if you are someone who hoards alot of analog phones and TCP/IP knowledge is second hand knowledge.
This is a work in progress and these are my documented notes to provide as a service to my followers if you are learning IP or learning VOIP and ether don’t have experience in networking. This series will bridge them together (at least that’s the intent.)
* I use all caps for most of all abbreviations/acronyms even if “over” or “of” or “as” are lowercase. I come from the background of using capitals just to make it look more professional and not some CraZY MySpAceGirl. 🙂
I’ll be talking about a project implementing basic VOIP services for a customer as a lab project. Before I go on I am keeping very technical details vague or withheld as this project is beta testing project for a customer of which I want to keep it confidential.
Lets drill down quickly on the Asterisk softswitch
- Contrary to the belief by the PC geeks, Asterisk is still and will never be a true “PBX”. Or at least compared to the ones made in the last 30 years. Asterisk is basically a PBX equivelent to the ones made before the digital ones, where it could make calls, receive calls and do other basic things in the modern sense like basic voicemail, basic conferencing and basic paging (if you’re lucky to get that accomplished!) Most I have seen in the various distros, the Asterisk can max at about 400 terminals and I don’t know tens of trunks. The Asterisk (and it’s respective distros) still miss out on many core PBX features that still haven’t been able to be reversed engineered.
- It’s mostly a snapon Linux service (that is more painful to snap on unlike a Windows service, without a distro.)
- I’ve used the now dated TrixBox CE, but also trying FreePBX and Elastix. Elastix is cool though in my application, I am using IBM Lotus Notes (transitioning from an MS Exchange setup) so I really don’t need email/calendar but the IM to me can be relevant in an IPT/UC setup. The official Asterisk releases I wasn’t too thrilled with, and release 1.7 I got reservations. The GUI one in R1.7 uses Google cloud UI – not good if you don’t trust in Google.
- Networking. The most amusing thing from these PC guys is you never hear QOS, VLAN and ensuring at least a four-nine reliability. The PC geeks believes everything will “plug and play” nice. If you think you can brag about setting up a “PBX”, think twice before you brag if you aren’t familiar with IP Networking Read on
Now I will focus on networking aspect as this is the core component of implementing any type of IP based PBX. (Including systems like Avaya’s IP Office which I run elsewhere at home.)
I am no networking expert, Three Letter Acronyms or TLAs go over my head, and often explaining things without proper detail or explain how each IP network are supposed to talk is limited online. I am the guy who likes things that will plug in and play when everything set up exactly (like TDM.) Sadly the IP and cyber world is not exact, physical and/or logical.
On the data front, I have a heavy data setup with mostly a single server running mini operating systems within a VMware server. Typically the CPU runs about 6 out of 9 production OSes, including an Asterisk (the TrixBox). The server runs on a dual core, 64 bit CPU with 8GB of memory with the ability to max on a quad core, 32GB RAM with specific 4GB modules per slot, which is the long term goal so I only will have to worry about one physical server. Of course, I’d like acquire a backup server in case the primary fails, which requires more money.
I standardized on ESXi since early 2013, but later changed to a VMware Server 2.0 because it doesn’t gel well with hardware and because of its 8 or so year age, it couldn’t do CPU virtualization or even mount USB ports or even detect any generic PCI cards that a VMware Workstation can (fax modems, backup Ethernet cards, etc.) This server ran ESXi 5.1 even when it wasn’t supported officially (which was a pretty cool version of the hypervisor), but unfortunately I had to go to a 64bit Windows Server running Server 2.0 on top (so I can go beyond the 4GB restriction if I went w/ the regular 32 bit release.) This tradeoff also works in case of a disaster (which this occurred in March before the downgrade) because a compatible VMware Workstation can take the virtual computers file and run (which eliminates the flip-and-convert process, which can take lots of time.)
What does this mean to the voice network? The Domain Controllers, private email, messaging and web and file services do take a lot of internal bandwidth (CPU resources are probably the most clogging). The file server is the common driver for the data traffic as files get stored, opened or moved, printers receive items to be printed and sometimes large (ISO discs) get moved onto this virtual file server. By the way: Asterisk currently runs on this same server.
The Asterisk VOIP System
The current setup are two Mitel IP Phones running on SIP firmware. The models are 2 5224 IP Phones, with paper desis. I’ve never used any Mitels before, only familiar with them in passing mostly the Superset TDM phones, like this guy I’ve posted a while back. Mitel’s IP phones at least in recent years have gone towards a cloud setup, even before “the cloud” got its name. Some phones I’ve seen from resales had logos from service providers like Sprint. Unlike Avaya, Mitel’s focus on the cloud is the hardware (like IP phones) while Avaya’s marketing is more software and in house or cloud based social platforms and less push to sell phones. (Always an equal opportunity offender here even if I am Avaya biased!)
Anyway, in this situation, I’ve set up the Asterisk as a form of SIP gateway. It will later be setup to have external VPN access through this system. This is mostly an internal communications system with a later plan to tie this to a PSTN remotely.
Think of this as an ol’ in house Centrex. Basically the featuresets are the standard Free PBX plus any SIP endpoint’s feature sets. Mitel supports on set call hold, shared line appearences, distantive ringing, call forwarding and Do Not Disturb.
The problem I am dealing with is spotty coverage, calls getting jittery and a lack of full fidelity. I realize some of this could be the virtual server itself . The Asterisk is running on 256mb of RAM and a hard drive about 40GB. I will have to put blame on some of it being a bloated Linux server, and another part not having an appliance, like a little hardware device.
Now some Avaya or even Cisco people would laugh at why would an Asterisk choke on such specs when an Avaya server with those same specs (sans a VM format) run fine at a max of 15,000 (IP only) for an Avaya or nearly 5,000 on a Cisco?
A part has to do with the protocol. I’ve come to understand that the first generation of VOIP/IPT systems were dependent on external hardware devices, and the phones running on a proprietary protocol like an H323 format. Avaya’s protocol that allegedly was modeled off their DCP (see glossary) and Cisco’s Skinny required a hardware endpoint to ether ring a non IP phone or to dial out, what’s known as a voice gateway. This didn’t require using the entire resources of the media server (known by some as the PBX).
SIP on the other hand is strictly software and strictly app based, since you know you don’t inhale your coffee, you “sip” or even your appetizer right, hahaha?
It’s so true. It is an app and it is very important to understand that the SIP protocol essentially makes your non H323 IP phone basically a switch in the phone. However to talk to other IP phones or non IP phones or to dial out, it requires a server and an application server to do this. This can be a pitfall depending on how much resources you have and how many phones and how important voice is to your enterprise. If you are using a low end PC, it might barely handle 5 endpoints.
Part 2 coming soon, notes for deployment and ensuring reliability.