Compare ShoreTel (SHOR) and CISCO (CSCO) Overview Part 1

August 5th, 2011

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.

6 responses to “Compare ShoreTel (SHOR) and CISCO (CSCO) Overview Part 1”

  1. Ami says:

    Does the ShoreTel system integrate with Asterisk or other open source systems? How does the cost and ROI compare to the open source model? Does it even make sense to compare the two? Looks like some of the features that ShoreTel and Cisco are offering integrators are doing with Asterisk and getting good results. Nice blog, really good into and in-depth technical writing. See my blog on open source topics, especially business, management and integration: http://bit.ly/tikalblog

  2. Skip says:

    Hi this is probably really useful information, but I’m finding it really hard to read. Admittedly I am not an expert in this area. But breaking up your text into different sections with section headings, and including some bullet points (maybe some bold words to pick out key words or phrases) would have really helped to make this more readable. (picky, picky!!)

  3. Spank says:

    Excellent article!!

  4. Gary says:

    Although this is over 17 months old, I can’t help but think others will stumble upon this and take it at face value and as current. This article is biased, inaccurate, and mis-leading through and through. Each paragraph in this blog has in-accurate or even blatantly false information.

    For instance, there has never been a “Business Edition 8, or CUCM BE8”. The correct product would be the CallManager Business Edition 5000 or 6000, which at the time of the writing of this blog, was running version 8.x, typically 8.5. I think for clarity sake, the most relevant solution would be the BE6K. This system does not and has not run on HP or IBM servers, but is positioned with Cisco Unified Compute System hardware, which at the time allowed for 4 (now 5) unique services (or servers, if you wish) to be installed. Top of mind would be the above mentioned Communications Manager and Unity Connection, with the next two most likely candidates being Unified Presence server for IM and presence and Unified Contact Center Express, both of which can be installed without additional hardware, unlike shoretel’s solutions (still).

    With regards to features not being relevant to the busines decision process, I call foul. Aside from cost, one of the leading factors in the decision process is always what features one system has over the other, especially as they impact a business process.
    Your description of the migration path, while basically correct in version changes, is inaccurate in the ability to migrate customers. Cisco has not abandoned or stranded installed customer bases as your article would lead the reader to believe.

    Furthermore, to boil this down to Phones & Messages only is incredibly shortsighted. Ask any potential customer of they are remotely interested in Video and IM & Presence, and most will express keen interest in one if not both.

    MGCP is NOT the primary protocol for Cisco’s UC solutions, and the location of the gateway is not the primary consideration for whether to use H.323 or MGCP. SCCP may have been in the past, at least with regards to endpoints, but Cisco has for a number of years been supporting dual stack implementations of SIP and SCCP based phones, and continues aggressively down the path of native SIP support, and in fact uses SIP to comunicate with a number of third party components and its own Unity Connection Unified Messaging platform.

    With regards to redundancy, I will concur that Cisco tends toward centralization, but you are very inaccurate in your description of the failure of the core meaning a loss of dialtone. Best practice designs always include inherent redundancy in the form of Survivable Remote site Telephony. By the way, how do you back up & recover a shoretel system? Do you need any third party applications to do that? (Hint: the answer is YES)

    As far as Unity “connector” (its Unity Connection), it is not a separate solution, it is part & parcel of the UC solution based on the Unified Compute solution, so it is just a virtual slice on the same box.

    Single Web Portal? Two words, Provisioning Manager. yes this is a bit newer to the line up, and I’ll even grant you that it is a direct result of Shoretel’s “easy button” approach to sales, but it does a bang up job of being a single pane of glass for provisioning. Oh, and by the way, its free on the BE6K, and it fits on the UCS server, so again, no additional hardware to buy.

    I could go on and on, but I wont. I don’t mind that you take a bias towards a certain manufacturer, I get it, you like Shoretel. I do ask however, that you at least be fair and accurate in your descriptions of the two solutions.

    Please turn in your CCVP, you obviously aren’t using it.

  5. Dylan says:

    Gary,

    I’d like to understand your reasoning for drinking the Cisco Koolaid: Let’s break down your long winded, nit picky reply and see how in the heck you sleep at night, shall we?

    Case 1:

    “positioned with Cisco Unified Compute System hardware, which at the time allowed for 4 (now 5) unique services (or servers, if you wish) to be installed. Top of mind would be the above mentioned Communications Manager and Unity Connection, with the next two most likely candidates being Unified Presence server for IM and presence and Unified Contact Center Express, both of which can be installed without additional hardware, unlike shoretel’s solutions (still).”

    Response1:

    What the hell does all this mean? You are complaining that ShoreTel has to add additional hardware in order to support all of these features. Gary, lets be real here for a second. You have to sell them an overly expensive M3 rack virtual server in order to install all of these applications. Way to go champ, you just told everyone that Cisco can finally virtualization the endless bolt on applications into one centralized server now instead of supplying separate servers for each applications… followed by exorbitant UPS requirements, followed by ridiculously complex and expensive designs for redundancy across all of these elements.

    Guess what, ShoreTel virtualizes everything except for our Fixed Mobile Convergence solution (ShoreTel Mobility) and the Conference Bridge/IM server. So we’ll go ahead and stick with our VmWare partnership; instead of creating a more complex and expensive version of an already accomplished VS solution.

    How much is licensing and SmartNet for the M3 rack server, plus all of the following acquired and rebranded products?

    Cisco Unified Communications Manager
    Cisco Unity Connection
    Instant Messaging and Presence with Cisco Jabber
    Cisco Prime Unified Provisioning Manager
    Cisco Enterprise License Manager
    Cisco UCS C220 M3 Rack Server
    You can optionally add the following collaboration applications to the Cisco Business Edition 6000 solution:

    Cisco TelePresence Video Communications
    Cisco Unified Contact Center Express
    Cisco Unified Attendant Consoles
    Cisco WebEx Web Conferencing
    Cisco Emergency Responder

    WHAT IS ALL OF THIS!!! Please rescue me from having to look over your 500 page quote sheet one more time.

    You also mentioned that in this BE6, you can support 4 server slices plus another for the Provisioning Manager. What happens if I want WebEX Conferencing, Emergency Responder, Telepresence… UH OH!!! I’m counting more than 5 applications? What do I do Gary? Guess what, we need a separate appliance for 2 applications…. you need additional infrastructure and possibly even a hardware upgrade for close to 5. We win. You lose.

    Case 2:

    “Single Web Portal? Two words, Provisioning Manager. yes this is a bit newer to the line up, and I’ll even grant you that it is a direct result of Shoretel’s “easy button” approach to sales, but it does a bang up job of being a single pane of glass for provisioning. Oh, and by the way, its free on the BE6K, and it fits on the UCS server, so again, no additional hardware to buy.”

    Response 2:

    Moot point, go home and learn how to make a valid argument. One part I specifically enjoy is that you mention how Cisco realized how great it would be to have a single management solution that can reach all applications within a single window. I haven’t seen this in action yet, but I already know it it no where near as easy to work through as ShoreTel’s Director software (ALSO FREE). Your point out again that you do not need any additional hardware!! I’m so excited for you Gary! Wait… it fits on the UCS server… ok so you need you still need a server to run this application like we do… which we virtualize just like you, and finally it comes down to we all need one server!! The difference is that according to you, it is a virtual server that Cisco provides… we just use what the customer has, or they can re use an existing server with the specs.

    Again: what exactly are your trying to say here? Are we just supposed to praise you and your Cisco buddies for finally getting your act together? “down low…. too slow!!!” You will always be more complex, have the largest laundry list of radical new product releases that never get used by the end user, and you will always fail in an architecture discussion when up against my self or any one at ShoreTel.

    Which brings me to my last case.

    Case #3:

    ” With regards to redundancy, I will concur that Cisco tends toward centralization, but you are very inaccurate in your description of the failure of the core meaning a loss of dialtone. Best practice designs always include inherent redundancy in the form of Survivable Remote site Telephony. By the way, how do you back up & recover a shoretel system? Do you need any third party applications to do that? (Hint: the answer is YES)”

    Response #3: Final Response- Fatality Round

    Gary, you don’t “tend” towards centralization. You ARE centralized. No one in their right mind is going to distribute the call processing with a multisite Cisco deployment…. which to do, your customer will have to literally deploy separate UCS virtual servers at each site, with duplicate copies of core applications lined together like silos under a centralized Provisioning Manager management solution at headquarters.

    Last time I checked, I’m still 26 years old, and thankfully did not have to live through the era of TDM and legacy phone systems. You just described what my 65 year old previous boss used to talk about when he used to sell Rolm, Meridian, and Avaya Definity solutions. Prehistoric architecture and completely separate phone systems at each location… I will give you one point for atleast finding a better way of managing separate phone systems under one network, instead of having to telnet remotely into each PBX.

    You had to throw out SRST!!! You failed to elaborate on this phrase, because you knew I would trample your peanut-brained attempt at explaining your own architecture. There is a huge difference between merely surviving on an island, and abundantly thriving off of my own resources.

    SRST is Tom Hanks in the movie Castaway… a grizzled man with a beard, struggling to find food, water and friendship, all while losing weight and sense of existence as the days (shall I say minutes for sake of telephony) go on.

    ShoreTel’s distributed architecture and appliances remind me of my Honeymoon in Tahiti with unlimited Jack and Cokes, lobster and fine delicacies, and a maid service that prepares my overly stuffed belly to fall asleep peacefully every night in satin sheets.

    Feature transparency and completely uninterrupted services during WAN outages. We don’t scream for our Parents at Headquarters when they decide to take a mini vacation while the fan blows out and its all systems down on the homefront….then some ugly baby sitter called SRST comes and finds us and helps us survive until we finally get manually picked up and rescued.

    I hope this picture sinks deep into your medula oblongata ( and yes I spelled that without doing a google search).

    I’m tired, as I’m sure you are from getting tackled like a gazelle.

    I will say this last piece: I back up and recover my ShoreTel system just like you do… in active/active replication and communication with another VM slice and a free duplicate copy of ShoreWare Director.. actually I can even do it with $30 16Gb memory stick and do software upgrades across 200 site locations in 4 hours, all while taking a customer who has 10 year old appliances and still giving them the latest and greatest that ShoreTel has to offer with no upgrades needed. I get happy customers and high Net Promoter Scores… you get pissed off companies with bleeding IT budgets, overly trained CCIE’s and over 50% of your customers saying they wish they would have gone against the Brand.

    Also, if you didn’t know, Cisco’s Telephony and UC revenues only account for 5-10% of the company’s yearly earnings. You aren’t that cool Gary.

    Good night.

  6. Jack says:

    Quite old post, but still interesting for me.
    I’m wondering about current redundancy features offered by both companies. Do you still see this as Castaway vs Thaiti?
    In my case its about 100 users, two locations and small group of phones (4-8) which should work regardless of LAN/WAN outages.

    Thnx,
    J

Leave a Reply

Your email address will not be published. Required fields are marked *

VoIP Directory

drvoip directory

Ask DrVoIP

ask drvoip

Network Readiness Assessment

drvoip readiness checklist

Is your network Ready?

Complimentary free download - DrVoIP VoIP Network Readiness Assessment Checklist (pdf)

Download Now ›

DrVoIP Planning Guide

voip planning guide

DrVoIP Planning Guide

A plain language VoIP guide for the business professional. (pdf)

Download Now ›

DrVoIP ShoreTel ECC Planning Guide

ecc planning guide

DrVoIP ShoreTel ECC Planning Guide

Complimentary free download - DrVoIP VoIP Network Readiness Assessment Checklist (pdf)

Download Now ›

Training Videos

shoretel ipbxcisco cusm
shoretel eccaudio voice prompts
cisco uccxcall back option
generic call queuecc admin
  

statcounter



free web stats


© Copyright DrVoIP.com 2017
Follow DrVoIP