We were deploying a new CISCO Voice Gateway, a CISCO 2921 with a PRI and mistakenly pointed a browser at the LAN Interface while searching for the CUCM URL! Sometimes accidents result in new information. We generally do not use Configuration Manger so we were very surprised when the browser returned the following screen.
What Can you do with it?
After the initial WTF? We started to poke around and what we found was more than interesting! This is a lightweight version of CISCO Configuration Professional, embedded in the router flash memory and it is enabled by default on newly Minted access routers. Currently, Version 2.7 is shipping and it has both an Admin portal and a User Portal. The Admin portal is enabled and shipped on the router. If you want to add the Use Portal (I have no clue why you would do that) you have to download and install additional software to flash memory. The System enables base configuration of key components like WAN links, VLANs, User, DHCP and SSID management. It has a Quick Setup Wizard and some interesting Router Diagnostics! There are also basic troubleshooting tools like Ping and Trace to assist debug efforts.
“Plug and Play” Option
There is also and an option for a “Plug and Play” server as part of the Prime Infrastructure support to automate remote deployments. If you are deploying a multi-site solution, this can significantly speed things along allowing for centralized planning, design, installation and management. Ship the router to someone who is capable of plugging in the right cables and off you go! The router finds the gateway, sends a request to the mother ship, identifies itself by serial number and can then download firmware and configuration files! Reload, up and running!
When folks wonder why they should pay more for a CISCO router when they can get Brand X for so much less, you might think about the impacts this can have on total deployment and maintenance costs! It had a great beat and it was easy to dance to, we gave it a 10!
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.
Lets take a look at the impact of SIP – Aide from the pure technology play, SIP represents a fundamental change in the economics of the telecommunications market. The carriage of telecommunications has been in transition with a steady migration for distance sensitive to usage sensitive pricing. Historically there where three components of the cost of a telephone call: origination, interexchange (e.g. Inter-LATA) and termination. The US telecommunications market has been moving toward a consolidation of service providers. Local Exchange Carriers (LEC) and competitive local exchange carrier (CLEC) is becoming as consolidated and the Inter-Exchange (IXC) carriers. Where do we draw the line on Enhanced Service Providers?
Generally, throughout the rest of the planet, telecommunications services are still owned and operated by government monopolies. Rural telecommunications for much of the planet is predicated on the payment of termination fees. If your favorite telephone company wants to interconnect with your parents in another country, they must pay a termination fee to the phone company in that country. This is not unlike the model of a US based LEC paying the IXC who paid a fee to terminate your phone call in another LEC. A complex price model and tariff structure exists even with the current “bucket of minutes” concepts borrowed from the wireless carriers.
At issue here is the impact of SIP phone calls made through the internet, both public and private. With the growing acceptance of SIP trunking and the development of E164, internet alternative carriage is also pressuring the move from TDM to VoIP. The Electronic Numbering Mapping System (ENUM) provides users with, what marketing people would call “experiential compatibility”. Being able to dial a phone numbers in the manner that users have become comfortable is absolutely essential to the success of the migration to and the adoption of VoIP solutions. SIP and ENUM work together to accomplish this.
The impact on the economics of telephony services is dramatic, both at the infrastructure level and and at the usage level. The cost of building packet switch networks, like the cost of build out wireless networks requires significantly less capital investment. The cost to the users will certainly not be distance based; but access and bandwidth based. SIP also provides for the increased use of multimedia communications solutions, also a bandwidth intensive application.
Sometimes there is nothing like a telephone lines mans test set to hear exactly what is going on! VoIP solutions have a double challenge: First it is hard to put a butt set on an IP connection; and secondly what happens when that connection hits a gateway at a remote site? This is always a fun situation. ShoreTel has a “trunk test tool” that has some usability. You can actually bring up the test tool, and right click a particular telephone line and place a call. If you are really in the fast reader group, you can set the test tool options to point the call at your own remote handset. In this way, you are sitting in NY, dialing out on a SF analog telephone line.
ShoreTel has another debug tool that is very useful for “hearing” what is happening on a remote analog telephone line at a site that you just cant get a handle on. You can literally telnet into the switch and setup up a recording session and capture the analog line sounds to a file back at your location. This will enable you to listen to the error message or lack of dial tone, locally enabling you to make the right decision about how to handle the trouble ticket.
The audio output of the analog trunk port is saved on the HQ or DVM server that controls the switch. To do this, follow this procedure:
From the start menu, navigate to the Control Panel> Administrative Tools and locate the IIS Manager;
Right-click on the IIS manager and select Properties. Then enable the ability to write to the FTP server by selecting the Write checkbox and clicking OK. This enable the ability to write to: C:\Inetpub\ftproot
At the command prompt, run the following VXWorks commands: Record2File2 (1, 60, “test” ) Audio data from running this command is stored in the file test_rx.pcm and file test_tx.pcm in the C:\Inetpub\ftp which will be stored as 8000Hz 16bit, Mono and can be listed to using a standard audio application.
Give this a shot the next time you are trying to “hear” if an analog line out at some remote location has any dial tone!
In a VoIP environment the WAN circuit is generally engineered to handle X phone calls of a specific codec. For example you might plan out a circuit that supports 10 simultaneous phone calls across the WAN between sites. You select the G711 codec and plan each phone call at 82KPS per call. This would require that there be a minimum of 820KB of bandwidth available or approximately 55% of a full T span. Given that the WAN connection also supports data applications, we want to assure that Voice does not take all available bandwidth! Interestingly when people complain about the bad quality of a VoIP call, it is generally the result of exceeding a bandwidth limitation, If you engineered the circuit for 10 calls, when the 11th call is placed, not just that phone call is trashed, but all 11 phone calls are destroyed! For this reason VoIP systems in general and ShoreTel in particular have strategies for limiting the number of calls across the WAN. In ShoreTel there is a parameter entitled “Admission Control Bandwidth” located in the Sites definition in the ShorewareDirector administrative web portal. This parameter assures that a call will not be set up between this site and another site, if that phone call would exceed the bandwidth setting. This generally eliminates the 11th phone call on a circuit designed for 10 simultaneous phone calls! ShoreTel switches or media gateways, know about the bandwidth they would consume when setting up a phone call and can take action based on this ACB parameter. We need to apply solid WAN engineering practices to the circuit planning however, as the ShoreTel switches will not know if that bandwidth is actually available! So it is possible that the ABC parameter will allow a call to be setup, but bandwidth may not actually be available as other data applications might be consuming more than planned bandwidth at that point in time. For this reason, we need to prioritize voice and data with queuing strategies in our WAN routers, the subject of yet another blog!
Has the economy hit VoIP? My thinking is that it has and in a very positive way for both integrators and voip service providers. Throughout my career I have always been amazed at the number of traditional key telephone systems sold into the small business segment of the telephone equipment market place. If you added up the numbers as published by the publically reporting companies in this segment, extrapolated an average SBE equipment size requirement you would conclude that every man, woman and child in this country already owns a telephone system! So where do all the new SBE phone system come from? Having said that, this number is getting harder to calculate as the companies that you could track in this segment (e.g.. Vodavi, Comdial, etc) have morphed into something else and generally as a direct result of the increasing acceptance of VoIP in that market segment (e.g. Covad, Packet8, Vonage et. Al). The economy even when it contracts, causes companies that survive to change their shape and size. We have witnessed a growing demand for companies seeking to spin off a branch office as a standalone business. If you have a CISCO Call Manager, for example, and you were running SRST at the branch office, we are servicing requests to convert the branch to a standalone CCME. Business Partnerships dissolve, the partners create new entities and split a perfectly good ShoreTel IPBX in two! Service providers in general, seem to be showing increases in VoIP revenue segments, specifically in the SIP environment. Cbeyond (CBEY) seems to be trading at near its 52 week high. Generally, my thinking is that VoIP is a good place to be no matter which way the economy moves!
