Implementing Asterisk as a Phone System, Part 2

This second part is on the core networking that VOIP runs on, the Internet Protocol.

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.

Hardware Setup

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, virtualization ready with 12GB 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.

If you are a business, I strongly recommend against using Asterisk even as a virtualized operating system. While virtualization is great to run multiple server operating systems, as one, my general rule applies, keep the hardware servers to serve files or applications, run another hardware server for domain controllers and firewalls. This will reduce the risk of security breaches. There are still some idiots in the world who run single servers to do multiple roles (a domain controller that also hosts public facing websites, or an Exchange server that also acts as a TFTP server – alright maybe the latter was made up, but just don’t be surprised to see similar insanities!)

I standardized on ESXi since early 2013, but in 2014 had to go to a X64 version of Windows 2003 with VMware Server 2.0 due to compatibility problems with the hardware. I’m stuck with ESXi as feasible solution to run as many types of operating systems meanwhile it can’t do basic things like tying to a USB UPS for backup and graceful shutdowns.

Asterisk works best if you have as much memory and resources as possible. A basic setup of a 512MB PC with a P4 is equivalent to a performance of a Partner 308. You add some memory and get a better CPU you could get an Asterisk to run equivalent to a Call Manager Express of just under a hundred phones and handful of trunks. If there isn’t enough resources, this can cause calls to jitter similar to a network clog.  Check the system, wether its virtual or the physical CPU first, it may be freezing up a little bit.

I do not use PCI trunks that Digium (the publisher of Asterisk) but I’ve done SIP connections between the virtual PBX and the hardware Cisco voice routers. This will be discussed in future installments

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. They pioneered the idea of “whitebox” hardware as 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 appearances, distinctive ringing, call forwarding and Do Not Disturb.

Bottleneck Warning 1 Call Ahead

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, as I already compared it to.

SIP’s cousin protocol is HTTP, aka the World Wide Web. When you go to a site like, the servers receive request much like making a telephone ring. If you get too many people trying to “call” web server, you’ll get a “busy signal” such as a 401 Error or 403 Error codes.

Sometimes these cyber busy signals are to do with a poor internet connection, too many people trying to get on a site (like a breaking news event) or the server itself is overloaded, and is ether crashing or the hosting backend is just frozen.

Unlike the H323 and proprietary protocols, SIP phones contact the server then the server will then forward the number back to a physical phone to make that phone ring. The proprietary protocols ping to the hardware which is supposed to be designed by manufacture standards to handle a certain type of traffic for a certain type of router or gateway. SIP is the Wild West, and if you aren’t aligning the right hardware to the right amount of traffic, expect bottlenecks and don’t blame your networking people at first!