Author: DrVoIP

All of the architecture “geek speak”  aside, CISCO and ShoreTel have fundamental “cultural” differences that defines their approach to the entities of  a “phone” and  a “user”.    Simply stated in the ShoreTel world a phone can not exist without a user, but the CISCO world a phone can exist without a user.  Now this is  not a bad thing or a good thing, it is a just the way it is thing!  What does that cultural distinction mean to you and your business?   Does it mean anything?   From a system definition perceptive, it does change how you think about your deployments.

In the CISCO world, you can bring up a range of phones, auto-assign an extension number, have a fully functioning dial plan  and never define a user!  In a ShoreTel deployment you can auto-register a range of phones, but they can not participate in a dial plan until they are assigned or “owned” by a user.   In one solution, the privileges that a phone has, like being able to make International phone calls, is set by the privileges of the user.  In ShoreTel a user is associated with a user group and that group has privileges associated with it.

In the ShoreTel world,  users are licensed but phones are not directly licensed.  You clearly have to have ShoreGear resources for the phones to register in the system,  but aside from the cost of the phone and ShoreGear switches, the phone is not directly licensed.   If you deploy that phone in the “Parts”  department you will need to create a User and associate that User to the phone.    So we now need to create  a user and user name like “Parts Desk1” and assign it to a phone.   Optionally, we could create a user named Tony Slavetore who works in the parts department, but that brings up the issue of of separating a “function” from a “person” which is an entire deployment discussion in itself and the subject of another blog.

In the CISCO world, you can have phones with extension numbers and they do not have to have a User profile associated with them.   In a CISCO deployment, phones belong to “partitions” and “calling search spaces” and that is what determines the phones privileges.    In fact the concept of a “partition” makes it possible to separate phones in such a way that “staff” for example, can not dial “executives”.   ( If asked in a ShoreTel system to restrict a phone from being able to dial a specific other phone, I would have to puzzle that one out ).   Again, this is not a which strategy is better discussion, but it is a distinct cultural difference that we seldom hear about.

The included video demonstrates adding a user and a phone in both the ShoreTel and the CISCO CUCM solution.  System Administrators will spend +80% of there time in this area!  Adding, deleting or modifying Users is a key part of the day to day maintenance of a phone system.

All telephone systems have to deal with the same key architectural  issues regardless of who manufactured the equipment.   All phone systems have to provide for the definition of a system “dial plan”; trunk groups, call flow options, phone devices, gateways and user profiles.   The dial plan, for example,  not only has to identify the patterns used to route callers between system extensions, but as is often the case in a VoIP deployment, between geographically distributed corporate locations or “sites”.    The dial plan identifies the legitimate patters that define system end points and also include system extensions.  System extension define various facilities and features with in the system.  The Automated Attendant, for example, has a system extension number that can not be used by another extension in the system.  Likewise so does the conference bridge, park feature, hunt groups and paging groups.

The phone system defines Trunk Groups which in turn contain individual telephone lines.  Permissions are defined within the system to enable access to these different trunk groups and also define what other facilities a user might  have access to.  Devices are defined within the system, typically consisting of phone instrumentation, media gateways to the PSTN or Remote Sites and collaboration facilities like conferencing and presence.  Other application servers are also defined in the system to provide for advanced functionality like Contact Center.

The entire subject of User configuration is contained within the system database as both a comparatively static form as well as a run time representation.    A user name and extension number, is an example of a relatively static configuration data parameter.   Which mode or state that users is in, would be an example of a “run time” state.   Which phone the user is currently assigned, where do their voice message reside and what restrictions have been placed on them are all examples of administrative options that need to be configured.
Both ShoreTel and CISCO have developed Web based interfaces to enable system administration.  ShoreTel argues a single “brilliantly simple”  portal to all system configuration facilities.  CISCO argues a level of control over configuration details that enable laser like configuration options.   For example ShoreTel operates on the concept of canonical dialing.  If a user dials 123-4567  ShoreTel will translate that into +1 (123) 456-7890.   CISCO anticipates  “dial-patterns” that make it possible to strip +1 (123) 456-7889 out from +1 (123) 456-7890 and route it differently.   The System Administration portal is the interface that is used to configure, define and revise all system options and for this reason it is as important as the phone set itself!

Over the next few blogs we will look at the actual web portal interface of both of these solutions.  In this first video, we will go over the portal interface in general, comparing both systems.  In subsequent blogs on this subject we will compare different administrative activities such as adding users, phones, gateways, sites and configuring call flows including automated attendants and hunt groups.

We are often asked for an opinion on the subject of what is better solution: a hosted “virtual” PBX or owning your own phone system?    Lets take a look a quick look at both solutions and see if anything stands out as making one solution more obvious than another.  First, let me lay out some quick assumptions!  We have to make some assumption about the size and scalability requirements for your phone system.  If you are a one or two man shop, don’t waste anymore time reading this blog, call Vonage or get a Magic Jack and be done with it!  If you are a start-up, and your hosting company is willing to provide all the equipment you need at no cost to you,  you can stop reading here also.   We assume that you are a viable business,  with some scale or plan to scale and  10+ desktops and “who can provided the cheapest “dial tone” is not your only criteria!

We have given the “your VoIP deployment is only as good as the computer network it is built on” so often, we will omit it here other than to say; crappy computer network, crappy phone service!  However, one of the biggest misunderstandings about “hosted” anything, is the issue of equipment.  Regardless of which solution you run with, you are going to need equipment at your place of business.  The equipment list includes:

• a high speed connection to the Internet;
• a Router;
• SIP savvy Firewall;
• Quality CAT5 or better Cabling!
• a Power Over Ethernet Switch;
• and the actual telephone handsets!

Much the way you would still need a desktop display and keyboard if you have a “hosted Microsoft Office”,  you are still going to need a handset and all the cable and connector stuff.  So then, from an equipment standpoint what is the difference?   Well someone has to provide the “box” that does all the Unified Communications Magic everyone wants in today’s business world!   All that Voice to Email, Digital Receptionists, Mobile connectivity and web based call control.  That box has to live somewhere and it is either in the hosted “cloud” or down the hall with the rest of your stuff!.  My guess is that you will not save much money on equipment by going “virtual”  phone or computer.    (Read Return on Investment.  At sometime you will own the box).

Lets take a look at that Internet requirement.   If quality means anything to you and your business, you are not going to be running a business of any size on a DSL connection to the internet if you are hosting your voice services in the cloud!   In fact the more of your voice that you move into the cloud, the more bandwidth you are going to need.  You don’t have to be a VoIP engineer to understand that when Bob picks up his phone to call Sue down the hall, the box has to connect them.  If the “box” lives in the cloud the we are going to use two times the band with for a simple office to office phone call.   If every phone call in or out of your place of business needs to go over that Internet connection, your own ramp is going to need to be very broad!   Generally, a dedicated T1 service will be required!  (Read increase variable monthly cost).

Quality will always be an issue for VoIP, again, regardless of where the “box” is located.   If every phone call is over the Internet then we need to understand that, unless the service is provided by the Internet provider you get your phone service from, you will have a quality issue.   What is this mean?   When we send anything over the Internet, we can not guarantee the quality of service unless we have a “private” path through the pubic Internet and an SLA (service level agreement) with our carrier.  Generally, if you are getting your hosted VoIP service from Cox, for example, and your Internet connection is provided by Cox you will have a more predictable experience.    If you are getting your VoIP  service from the “The Big Box in the Sky VoIP Company” and it is delivered over a COX circuit, you will not have the same level of service.  That is a fact.

Business continuity and disaster recover?   Clearly, if you lose Internet connectivity, you lose everything.   Hopefully your VoIP service provider continues to handle phone calls and allows you to re-route your phone calls to your cell phone! (Read, feature check list addition).   Actually, this is one area in which I prefer to design with a “hybrid” approach.  Regardless which solution you go with, I would argue that you need both Internet and Local Telephone lines.  If the Internet goes down, you have your local telephone lines to fall back on.   Like wise, if your local lines go down, you have your VoIP dial tone to make use of.  The bigger issue is this:  In a hosted or “virtual” solution where would you connect some local telephone lines for back up?  Remember the “box” lives in the cloud!

The “hosted” world, both computer and phone, boast that virtualization will enable you to free yourself from maintenance, backup and some electricity!   Not sure if I can buy into this, as we still have all that equipment onsite we have already outlined!  Someone still has to take care of that equipment.   Have you called your favorite credit card company lately?  How was the customer service?   So now that we have killed off our onsite tech support, we are going to bet that the hosted provider has a customer service organization that is more responsive to your business than your credit card company?

Application Integration?   If you have unique applications, your “hosted” provider may not be able to accommodate you.  Many can integrate with Salesforce.com but if you are using a proprietary Medical, Dealer Management, IVR, Predictive dialer or if you have extensive call center needs, this may be an area that will be a key determinant in your decision to host or own.  This seems to apply to hosting your computer system as well.  The more you move outside the basic Microsoft Desktop Office Suite, the more difficult it gets for “hosted” providers to accommodate you.   You may also need to evaluate any regulatory “compliance” issues as they may also dictate what you can do in a hosted environment.

At the end of the day, VoIP over IP “dial tone” has some real value in either solution.   You are able to get DID numbers form any geography around the country or around the world!   You do not have to have a “hosted” phone system to get this functionality, however.  We can bring VoIP DID lines into any telephone system, so that is not a determining issue.  What then is the determining issue?  If you think like we do, you want the best of both worlds!  A hybrid solution!  VoIP lines or SIP trunks, remote access for my mobile workers/branch office and back up telephone lines on the back end!  I think the CFO needs to get involved here as there is no way that renting forever, can compete with the ROI of a equipment purchase!

Lately, we have been playing with a Windows based solution offered by 3CX.  We remember the “UnPBX” products of the late 90’s early 2000!  There were a few companies that tried to build PBX systems on Microsoft Platforms like Windows NT.   Popular gateway cards were produced by companies like Dialogic and inserted on the back plane buss of a Microsoft engine.  Unfortunately rebooting your phone system everyday was not received well and these products fell to the wayside.     Our personal experience with COM2001, Alexis and Xantel were part of our learning curve! We approached the 3CX product with some trepidation because of these early experiences, but we were pleasantly surprised at how far this product had come.    In the SIP world, it is not necessary to put gateway cards for analog or PRI connectivity in the Microsoft engine.  You can use an external gateway of your choice or do a complete deployment using only SIP trunks.

The 3CX is a fully featured phone system with all the bells and whistles for a Unified Communications platform.  It runs on the most current version of  Microsoft Desktop or Server OS.   For a small installation you can bring it up under Windows 7 using a small PC hardware platform.  As the demand for redundancy, scale, backup and memory expand the Microsoft 2008 Server makes more sense.  What impacted us the most was how easy the initial installation and system bring up were.   With all our product evaluations we use these basic criteria:

• Ease of Installation (qualitative judgement)
• Administration Process (GUI or Command Line)
• Phone Provisioning (automated or manual)
• Feature Set and Licensing options
• Automated Attendant and IVR functionality
• Integration with popular CRM
• Mobility Options (find me follow me)
• Multiple Site and Remote User Connectivity
• Call Center Options

With this list in mind, we would rate 3CX very high!  The installation was flawless.  We downloaded a free copy from there Webiste and later obtained a license key that opened up the full feature set.   Within 30 minutes we had operational telephone extensions defined and working.  We create SIP trunks to our provider and had outside dial tone connectivity as fast as we could complete the SIP trunk definition.    We provisioned the first few phones manually, but later setup the appropriate profiles for auto provisioning.   The 3CX was following the best practice of the big boys like CISCO and ShoreTel.   Using DHCP options, we could stuff a new phone with its extension and feature set.   We also brought up the 3CX soft phone application on an apple iPhone!  Again, this was very straight forward and registration with the mothership and connectivity with the other phones was as straight forward as the implementation of an onsite wired phone.

The feature set covered the minimum daily adult requirement for phone usage.  The advanced feature set was impressive.  Call Queuing, recording and message notification options were all available to the individual users through a web based application.   Each user had the option of bringing up a browser and having a visual call control application for their individual extensions.  This was impressive, but the integration with Microsoft Outlook Salesforce and Exchange was equally available and effective.  We noted a HTTP api that seems to enable integration with any application that supported web based CRM.

The Automated Attendant was robust, but our real focus was on tenant services.  Many small business have multiple identities under one roof.  If the client wants to be able to have one phone number answered by an Automated Attendant with a script for Company A; and another for Company B this simple requirement sometimes knocks out a contender.  The 3CX handled this brilliantly and we were able to direct a caller to  different Automated Attendants or Digital Receptionists based on the number dialed.   You would think all phone systems can do this, but you would be surprised to find that many can not.  We love the CISCO 320w, but if tenant services was a requirement, we would not be able to meet that expectation.

Mobility options enabled a caller to an extension set up with a “find me follow me” option to reach a cell phone.   Again, this is a feature that is becoming an absolute standard for a VoIP deployment!  3CX was able to do this quite easily and also enable the individual user to manipulate these options without the need for the System Administrator.    The last couple of steps we are just playing with and will report more as we explore the Call Center and Site options.   Technically, we see no reason that we can not have remote users.  The key issue is, can we plant a 4960 type PRI gateway at a remote location over a WAN and operate a remote trunk group.    More on this later, but we are eminently impressed with the 3CX product and would recommend it for a small business deployment, or as a remote site for a large ShoreTel or CISCO deployment.

Interestingly the system is licensed not by features, but by simultaneous calls.  A very interesting approach!   You can set up a system with a 100 extensions, the issue is how many calls will the system allow.  Do you license the system for a 100 calls?   Not likely, but you would have to make a determination as to how many of your 100 extensions can be making use of the system at the same time.  Generally, we like that licensing strategy.   Other systems might be licensed based on the number of extensions.  In a ShoreTel deployment, for instance, you would be paying some $20,000 dollar in license fees to bring up this 100 user deployment.  Licensing based on simultaneous calls is an interesting approach and it is being adopted by most of the systems that are sold and supported by other than the freeware community.

At the end of the day , your Dad was correct when he said “you get what you pay for”.   Yes you can download a free phone system from the internet.   We should all thank Mark Spenser for the creation and contribution that Asterisk has made to the telecommunications universe.  The derivations of this contribution are global!   More an more new products are based on the core contribution that Mark has made.   Unless you are a true phone geek and you want to play with Linux and Asterisk code all day, you are not going to create a scalable, supportable telecommunications platform without an organization to stand behind it.  Yes community support is available, but at the end of the day, you want a 1-877-DrVoIP1 number available that is answered by a support organization that can be there when you need assistance.  ( We have arranged some exciting packaged solutions with our partner VoipLink so see our DrVoIP Recommends section or click here for a sample http://www.voiplink.com/product_p/3cx-cisco.htm ).

We will continue to review the products we support!   Our current list of supported products has now grown from ShoreTel and CISCO to include Digium,  Elastix, Astrisk in general and 3CX when it comes to a Windows solution.   If you are planning a VoIP deployment of less than 100 handsets, 3CX offers a fully feature Unified Communications solution at a price that is compelling!

Since we published the blog on the ShoreTel SIP implementation using Ingate, we have been deluged with requests for more detail.   Specifically, people want to know if there is a more economical  solution for bringing  SIP dial tone into the ShoreTel architecture when you are trying to add just a few local lines to a branch office.    Historically, given the feature depreciation that users might experience with a SIP trunk on ShoreTel, we had discouraged the adoption of SIP dial tone entirely!    In fact, if you already have a ShoreTel T1/PRI supporting your deployment  there is little economic benefit to be gained by replacing the PRI with SIP.   After all you already own the PRI gateway and now you have to go buy an Ingate box.  Might make sense for a new deployment, but it does not make since for an existing deployment or for adding just a few SIP dial peers at a remote office location.

Well then, what about, keeping the ShoreTel PRI but bringing the dial tone in over a SIP trunk?

The fact of the matter is, that many carriers do bring the PRI circuit in over a SIP trunk!   They then run the circuit through a Integrated Access Device (e.g. IAD) that converts the SIP trunk to PRI and the resulting hand off to the ShoreTel is a traditional TDM flavor of PRI.   This makes the carrier happy and the ShoreTel PRI continues to operate with no feature depreciation as everything from a ShoreTel perspective remains TDM!   The original investment in ShoreTel equipment is protected and you get some of the benefits of having a SIP trunk  like foreign DID’s and more fail over options.

This got  us wondering if we could do the same configuration by rolling our own?  We came up with two solutions.

First we created our own SIP Appliance using a low cost Linux box running CentOS and our favorite Asterisk dis tro, both of which are available as freeware.  For the SIP to PRI configuration we added a Digium T1 card bringing our total hardware cost to less than $900 for both the PRI hardware and the Linux computer!   Next we setup a  simple T1 Tie line between the ShoreTel iPBX and the SIP appliance.   We then created an IAX trunk to our SIP provider from the WAN side of the SIP appliance,  assigned our DID’s to the SIP dial peer and we were up an running in no time!  The configuration is a classic B2BUA and it works just like the carrier provided CISCO or Adtran IAD!

Next we set out to build a SIP solution that was a pure dial peer with no TDM hardware at all!    Lets assume you have a remote branch office and you would like to provide a local DID for that branch.   Using a SIP DID and less than $500 dollars worth of Linux computer hardware ( see our blog on the Shiva plug) you can easily make this happen.   We used the same appliance we created for the PRI conversion, this time without the Digium T1 card.   We specified the remote SG50 as the IP trunk source and terminated it on the SIP Appliance.  Again we created a SIP dial peer from the Appliance to the SIP dial tone provider and assigned our DID numbers.  It worked flawlessly as a simple, end point SIP dial tone solution providing local DID numbers to that remote branch office.

One of the challenges of ShoreTel is that the entire architecture needs to be described, from an IP topology, inside a private address space.   That is why you can’t just interconnect a ShoreTel SIP trunk group with an ISP.   When establishing your SIP Peer to your provider,  you are generally going to link with a public IP address.  Using our SIP appliance we were able to bring up a remote branch office with an end point that supported 4 SIP Peers and used a local DID for that branch.     (ShoreTel SIP trunks are licensed in packages of 5, while all SIP dial peers provide dual channels?) Again, the SIP trunks between the ShoreGear SG50 and the SIP appliance was created completely within the required private IP address space, yet the appliance interfaced with a public IP address to create the multichannel SIP dial peer.    The Asterisk configuration we created enabled us to configure on the LAN side of the firewall, yet specify a public IP address for the dial peer end point with no NAT issues to contend with.

At the end of the day, there are a variety of solutions for bringing SIP into your ShoreTel deployment!  Sometimes the best things in life are free!  We are no busy integrating the ViciDialer with ShoreTel to provide an enterprise class Outbound dialing solution for the contact center using freeware! More on this later……