As both a ShoreTel Certified VoIP Engineer and a CISCO CCVP I have been working exclusively in VoIP since 1998. For this reason, one of the questions that is most asked of me is which is a better solution: ShoreTel and CISCO? Since I have the sales skills of Attila the Hun, I assume that the question is being asked because someone is truly interested in understanding the architecture of the two systems. At the end of the day most people just want to pick up the handset, hear that warm reassuring sound of the dial tone, press some digits and talk to their target! How that all happens is generally of little interest to the average user. So why else would you ask that question unless you were generally interested in understanding the two systems and how they compare when resolving traditional telephony applications. I thought it might be useful to drill down on the two solutions in a few key areas toward the goal of understanding how they both work.
First, which systems to compare? CISCO actually has a family of VoIP solutions under the brand banner of Cisco Unified Call Manager. For example, they have a small 24 user system that is marketed under the model 320W. The next model up would be the UC500 series, then the CUCM-Express and finally the CUCM. Even the CUCM has different models. The most recent edition, the Cisco Unified Call Manager Business Edition Version 8 is a 500 seat, 5 site variation of the full blown 40,000 user Cisco Unified Call Manager. Since ShoreTel actually has only one product family that can take you from 25-10,000 users, I chose to use the Cisco Unified Call Manager Business Edition (CUCM BE8) as our comparison product.
Both product lines support a range of Unified Communications Options that include Contact Center, Presence, IM, Video Conferencing and Microsoft Integration. The list of options goes on and on, so where do we draw the line in our comparison? My thinking is that we stay focused on the basics: the telephone and Voice Messaging System. In this way we can look at the two architectures and free ourselves from the additional servers most of the options will require. Lets keep it simple!
Let me first make a blanket statement about telephone system features and “feature sets”. For a very brief period on the calendar, one system might have a feature that the other system does not have. Understand that within six months, both systems will not only achieve parity, but will reverse roles. The one that did not have the missing feature, will now have it and the other one will be missing one! My sense of it is, that you would no sooner buy a phone system because you like the color of the phone than you would because it had a feature that was not available in the other system. I guess it is possible that someone would make a purchase decision based on that criteria but features are maturing all the time and with major feature releases usually twice a year, all phone systems achieve feature parity very quickly. So this brief comparison is not going to talk about features at all. They are both the same, lets drive on.
One high impact characteristic that is of immediate interest, however, is the concept of Software Versions. ShoreTel is currently running on release 12, having migrated over the last ten years from Version 3. Without exception, each release of ShoreTel has been backwardly compatible with the previous version of ShoreTel. What this means is that If you purchased hardware from ShoreTel in 2001, you can upgrade it today to Version 12 in 2011. Both companies have been slowly migrating away from Microsoft. ShoreTel and CISCO both came to market using Microsoft Servers and Microsoft database utilities. CISCO has moved more aggressively in this area, shedding Microsoft Server for Linux, but with a heavy toll on the installed base. If you were on Version 4.x of Cisco Call Manger there is no easy upgrade path to CUCM BE8 and prior versions are either not supported or end of life.
ShoreTel is still using Microsoft Servers though one might project a product road map in which they move to Linux. Historically, ShoreTel used Microsoft Access as the configuration database for its phone system and call detail records. By Version 8 ShoreTel had moved from Microsoft Access to MySQL for all of its database requirements. This transition was made with nominal breakage and early ShoreTel adopters can continue to upgrade to later versions of ShoreTel. CISCO database was built on Microsoft SQL engine. Cisco release 4.2 ran on Windows 2000 and Version 4.3 was implemented on MCS OS 2003 a Cisco proprietary version of Microsoft. With the release of CUCM 5, Cisco moved to the IBM Informix database running on a Linux engine (Cisco VOS). Cisco 6 moved to Linux Red Hat Enterprise and would no longer support the previous Windows based Call Managers. Cisco Version 8 was introduced in 2010 and is now the current release for the entire CUCM product line.
ShoreTel uses the Microsoft Server family and currently supports Windows 2008 64 bit OS servers. Cisco began to support virtualization under VMware in Version 8. ShoreTel began to support VMware virtualization in release 11.2. Generally ShoreTel will allow you to pick your own hardware provided it meets the basic server requirements for the release being implemented. Cisco requires the use of an approved MCS server, generally an HP or IBM hardware platform. A key difference is that under Cisco, the server is considered to be an “appliance”. Aside from being able to set up the network parameters, the root is completely unavailable to the maintenance of the system. On a ShoreTel system, you have complete access to the underlying OS as the system administrator. Treating the hardware as an “appliance” while hiding the OS does have its advantages from a support perspective. On the other hand, most IT managers will be very uncomfortable with a server that does not allow access to the base OS.
Culturally, Cisco is defined by extension numbers and ShoreTel is defined by Users. It is a subtle but very interesting differential. Both systems will allow you to auto provision a group of phones. In Cisco you can arrange to automatically assign a range of extension numbers sequentially to phones as they come up and register on the network. The auto registration process can also assign calling permissions to those phones. In ShoreTel you can bring up a group of phones and they will automatically register over the network with the system. The ShoreTel phones will, however, not have extension numbers. They will be “available” which means they can not be called until they have a User assigned to the phone! This means the calling permissions are based on the User not the Extension number. Cisco allows you to assign a User to the phone, but the concept of an extension can exist independently of a User profile.
Both solutions offer the ability to integrated geographically distributed locations into a single call handling plan. ShoreTel has a distributed call processing model and Cisco uses a centralized call processing model. When Cisco is deployed using a distributed call processing model, this means that a separate Call Manager cluster is setup at that remote location. The deployment models for both systems can get complex quickly, but the best way to understand the impact of the deployment model chosen is to study the failure mode. In the Cisco model, your phone registers with a Call Manager server. No Call Manager Server, no dial tone. For this reason the Cisco best practice is to have multiple Cisco Call Managers in a cluster that phones can register with in the event of a single Call Manager failure. The ShoreTel solution has the phone register with a Shoregear switch, a hardware appliance or what Cisco would call a “media gateway”. If the ShoreTel HQ server fails, the phones still have dial tone and phone calls in and out are still completed. If the Shoregear hardware appliance that a phone is registered with fails, the phone can register with another resource anywhere in the system. The loss of the ShoreTel Server has impact only on the Voice Mail and Automated Attendant.
Both systems make use of similar call processing protocols, most notable of which is MGCP. Cisco phones communicate with their Call Manager using a Cisco proprietary signaling protocol referred to as “skinny” or SCCP. The Call Manager communicates with its Media Gateways using MGCP if it is loc ally attached or H323 if it is a Gateway across the WAN at another site. ShoreTel phones communicate with the Shoregear Switch they have registered with using MGCP protocol. The Shoregear switches communicate with each other using SIP. Both systems also support SIP end points including SIP extensions and SIP trunk lines.
System administration and support are also key areas in which you will want to drill down for comparison purposes. The best way to understand this difference is to actually log into both systems and do something useful like add a user. ShoreTel has a single web portal in which the system definition is configured and through which adds, moves and changes are made. This is one very key differences in the architectures of these solutions. Remember, the ShoreTel is a self contained solution that includes the Voice Mail system. The Cisco solution requires a separate Unity Connector voice messaging system. So when adding a user for example, in the ShoreTel you would create your user and simultaneously create the directory listing and voice mailbox. In Cisco this would be separately configured system administration interfaces.
ShoreTel Shoregear Media Gateways, are very similar to Cisco gateways but differ in how they are configured. Bringing up a T1/PRI at a remote site in ShoreTel is no different that building out a T1/PRI in a locally attached Gateway. It is all done through the ShoreTel administration web portal. In Cisco, you would define your T1/PRI gateway, but you may be required to actually go to that device and code at the IOS command level. You can use the Cisco web administration portal to define the gateway device, but the device itself is often configured separately in IOS.
I think I will leave the entire subject of fail over to a dedicated blog on that subject. Again both solutions have a strategy for dealing with the loss of a WAN link, and they provide for the continued operation of the disconnected remote site. How they each do this, is really quite different and deserving of a dedicated blog. The issue at this point, is how to administer that fail over capability and how to configure the system for continue operation. Cisco SRST (Survivable Remote Site Telephony) is an interesting set of administration tasks that requires a bit of explanation. Basically a remote site becomes a Cisco CCME and continues on as an independent operating entitiy and will require manual intervention to bring it back into the main system when the Wan is available. ShoreTel, requires no additional configuration beyond what was defined in the original system deployment and no manual intervention is required.
The film clip below reviews most of this text, but will also show you what to expect when you log into each solution. First we take a look at the ShoreTel solution and then we log in and take a quick tour of the Cisco administration portal.
