Architecting voice and data for the SMB – part 1

One of the advantages I have in my current job role is being able to research, test, and deploy all facets of enterprise technology. I am by trade a “server guy” but I have some fairly extensive experience on the network side of things as well, L2/L3 switching and firewalling mainly. I have had VOIP running at home for many years now and did a very small implementation for a startup years ago. This is my  first enterprise installation.

Call Managers

The two top contenders in the enterprise voice world are Cisco and Avaya. People swear by each, it depends who you talk to. My perception is that Cisco is the “Cadillac” option and there’s a saying in IT, “No one’s ever been fired for buying Cisco”. While both vendors have similar offerings and options with regard to call managers and IP phones, Avaya is typically cheaper all things considered. I’m building out a brand new datacenter infrastructure as part of my efforts which means I need new switches and firewalls. This is where the Cisco voice option makes the most sense. Serious discounts are to be had by buying voice gear bundled with core infrastructure. Cisco is very serious about not losing out on voice deals and make it very hard for competitors while pricing new build-outs.

Cisco has four essential options when it comes to voice platforms, all falling under variations of the moniker Cisco Unified Communications Manager. I’m still partial to Cisco’s original product name Call Manager, but I digress. CM can be purchased as:

• Express (CME)
• Unified Communications 500
• Business Edition (CMB)
• and full blown Communications Manager (CM)

Here is the  short take on the differences: CME is a voice enabled router with a CME vWIC (add-on card). The basic CM functions are handled but this solution is intended for very small environments. UC 500 is a stackable appliance that tops out at 64 phones. CMB is a hardened appliance (an OEM’d HP DL320 painted Cisco teal) that is capable of running the full functionality that CM can offer but is locked to a single appliance. This level in particular has a leg up on Avaya as CMB contains the Unity Connection voice mail system baked into the appliance. Avaya’s comparable IP Office product requires a separate server to handle this function. Full blown CM has the same essential feature sets as CMB but it can be run on various “Media Convergence Servers” (MCS) that vary in specs, and it’s clusterable. The CMB appliance is based on the MCS 7828 platform.

Getting to the PSTN

We have a few options when it comes to providing connectivity for our voice services. Yes VOIP is voice over IP but this does not mean you can simply run it over your main data circuits like you do your Vonage service at home. Telephony is an important aspect of business operation and not only deserves a dedicated solution, but requires it. There are two primary means for connecting to the PSTN (Public Switched Telephone Network), PRI and SIP.

Primary Rate Interface circuits (PRI) are channelized versions of traditional T1/T3 type circuits. A T1 contains 24 channels, 23 of which can be used for placing calls, the 24th is used for signaling. Oversubscription is common and practical so for architecture purposes you have to consider how many simultaneous outbound calls your environment is likely to experience. Internal calls are switched through CM and do not cross the PRI. So for 100 users you could probably safely plan for the likelihood that 40 people might be on the phone at once. Call centers would be thought of differently, obviously. To satisfy those 40 calls, however, you will need 2 PRIs (T1’s).

Session Initiation Protocol (SIP) is purchased as a “SIP trunk” which is an IP connection that permits voice traffic to be routed over the backbone of the carrier. The advantage of SIP is that it’s purchased by bandwidth increments (3Mbps, 5Mbps, etc) which can be increased easily and is normally cheaper than an equivalent PRI. It can also be used for voice and data traffic. The same basic principle of the PRI applies to SIP when planning for oversubscription. 1 x PRI (1 T1) = 1.5Mbps so 1 x 3Mbps SIP trunk is equivalent to 2 x PRI’s.

Voice experts that I’ve spoken with at Cisco and Avaya still think a pure SIP solution is too immature today in terms of call quality. Both recommend at least a partial PRI solution for primary calls and leveraging SIP for call spillover/ redundancy. I’ll go into this deeper in the design. Another important consideration is to ensure that the voice carriers are the same for SIP/PRI, especially between sites. If different carriers are chosen and the primary circuit fails, carrier B would not be set up to receive calls for the company’s DID’s (phone numbers).

Design

My design consists of a two-phase approach providing primary voice services for a main campus location, with acceptable levels of redundancy, for phase one and DR voice services for phase two. Cisco guarantees a 4-hour response time but we can’t have a 4-hour voice outage. Of the choices available CMB makes the most sense for my design. I need to connect 100-125 phones, sustain at least 40 concurrent outbound calls, and, barring facility complications beyond my control, guarantee 99.9% onsite uptime. CMB is a feature rich appliance with redundant hardware features and carries a price point that fits my budget.

For onsite redundancy with CMB there are three viable options.

• Cold spare appliance
• SRST-enabled router
• CME-enabled router

Configs can be backed up and imported into a stand-by appliance which is fast and easy from a recovery stand point. The problem is that this solution isn’t cost effective. Survivable Remote Site Telephony (SRST) can be leveraged in a number of ways. It can be used to provide high availability for the main campus or to protect branch offices from a CM failure in the main campus. Connected IP phones will register the SRST router as a call processor so if there is a problem with CM, SRST will take over telephony operations seamlessly. Functionality is reduced to basic call processing in SRST mode but that is what’s most important after all. CME is also a viable option but isn’t as cost effective as SRST.

Sizing your main campus SRST router is important to ensure that it can sustain the same level of calls that CM did. For my design I’ll be using a voice-enabled 2851 router for the main campus. For DR considerations you can’t have a remote SRST router handling calls for the main campus in the absence of CM, this is a per site limitation. To provide that level of redundancy we would need to deploy another CM in DR. For my DR purposes I can deploy a smaller (cheaper) 2801 router which will serve as a voice gateway for CM in the main campus. What this design buys me is network redundancy should something happen to my 2851, PRI, or SIP circuits in the main campus. CM will route, via IP, to DR and use the SRST router there as the gateway to the PSTN. Budgeting prohibits me from making my design completely bullet-proof so I have to account for as many scenarios as I possibly can.

Leveraging both PRI and SIP circuits in the main campus accomplishes three things. Should the PRI circuits fill up, i.e. caller 47 picks up the phone, this call would be routed out the SIP trunk. Should the PRI circuits fail for any reason, CM will route calls out the SIP trunk for the duration of the outage. Should the primary internet data circuit fail, the SIP trunk will serve as a backup for internet access.

My architecture will satisfy the following objectives:

• HA for CMB in the main campus via SRST
• Redundancy for main campus voice circuits via deployment of PRI’s and SIP
• DR to protect against main campus PRI, SIP, or SRST router failures

I will talk more about switching, security, IP phones, and data circuits in part 2 of this topic. Here is a high level view of my overall architecture: