Deploying ShoreTel – A project managers notes!

Having deployed literally thousands of phone systems of all sizes and levels of complexity, we have distilled a set of rules and check lists that work.   (see our “network readiness check list” and our “VoIP planning guide”) When phone systems were analog or traditional TDM based solutions,  deployments were challenging enough!  You always had the User group, Call flow and “K plans” to hammer out along with the usual Telephone carrier challenges.  With VoIP solutions however, the level of complexity has dramatically increased.  This technology touches so many other infrastructure domains that it is becoming increasing more difficult to draw a box around what is included in the project!   Consider that you are required to  integrate a phone system with Active Directory,  Exchange, CRM applications and deploy over a geographical topology that might be global in scope!  You need a road map for success and  project management becomes an essential component of a successful deployment.

The first post sale step should be to organize a “kick off” meeting.  The kick off meeting  is an opportunity to set expectations and establish guidelines that will help complete the project on time and within budget. When you leave the kickoff meeting, everyone on the project team must be on the same page.  It is imperative that we identify the key “stake holders” in this project.  Minimally this list has to include an Executive sponsor, the Account manager and the Project manager.    During this meeting you will want to spell out goals, objectives and deliverable identities then obtain “buy in” from the kick off team.   You will introduce the project team members and identify their individual “roles and responsibilities”.   Setting a target for “go live” often helps drive the milestones that have to been executed if that time line is to be achieved, so I am a big proponent of working backwards from a target date!   Developing a contact list should be accomplished at this meeting and if the project will use a web portal for communicating, it should be demonstrated.   Allow for the possibly that there may be outside vendors that need to be identified at this time and added to the contact list.  Finally, assign “home work” and set due dates for the next meeting.

The kick off meeting is almost a social event and is a time for people to associate names and faces.   It is not a working session, but an effort to set expectations for all that will be either on the project implementation team or will be impacted by the implementation process.   There is a wide range of personalities and skill sets at a “kick off meeting” so it is important to adopt a language that is comfortable for all.  The team will consist of very technical people, financial  professionals and technology consumers (We are trying to avoid using the work “users”.  There are only two industries that call customers users.  The IT community and the drug trade).   It has been my experience that we will almost always get all of the technical stuff settled; all the speed and feeds, bits and bytes.   The area that is always the most difficult to extract is the Call Flow information .  For this reason it is imperative that the team have a representative that can speak for the User group.   Someone has to define a callers experience and the scripts that are head by the caller as they progress through the telephone system (see also: http://www.blog.drvoip.com/call-flow-the-callers-experience-when-reaching-your-business ).

Some of the internal players that will need to be included on the implementation team are responsible for key infrastructure components.   Active Directory integration is now almost always a part of a VoIP deployment.   Messing with a companies domain and user authentication polices are never take lightly and you will need to get key intellectual resources involved to pull this off successfully.   Clearly, the computer network both LAN and WAN will touch the the new phone system and this area requires even more planning and communication.  Generally, there will be outside vendors involved especially as it relates to the WAN connectivity.   Getting the carrier to the table early on in the process will greatly facilitate the success of the project.

Facilities management or property management and the bag full of deal killing goodies needs to be addressed early on!  If you are deploying in a “greenfield” you will have a different set of challenges then if you are replacing an existing phone system.   Often a “greenfield” is another word for “new construction” and construction always means scheduling conflicts and delay.  This is where your project management software really gets exercised!

The actual deployment of equipment is almost reduced to a task list. Properly managed most of the heavy lifting has already been accomplished before the equipment is actually installed.   The network has been assessed, made ready, routes updated and QOS applied.   The user database, IVR scripts, trunk facilities, Extension lists, Hunt groups and system definition have already been programmed.   We are down to “rack and stack” and set placement in anticipation of exercising our detailed system test and acceptance process.

It is about this time that we will want to have the Training team make an appearance.    Generally, it is best to schedule user training as close to the “go live” dat as possible.  We have found that we can brake user training into two groups.  The first group is a an abbreviated session design to assure that all can answer an incoming call, park, transfer and conference.  If users can do that by “go live”  only good things can happen.    The second group is an extended session augmented by multimedia and other online solutions.  This training is for your power users and special users like Operators, Agents and Supervisors.  Actually, this is a process not an event and your training program has to be ongoing over the life of the deployment.   People come and go in any company.  Your reputation and phone system stay. Make sure new users have a good impression!

The “go live” is also more of a process than an event.   Moving the old numbers to the new phone system, might be a single task in time, but it is part of a process that includes a series of collateral events.  For example, how do we get our Voice Mail off the old system?   In fact, what happens to the old system?   Was Garbage removal in the project plan?   A new VoIP deployment needs a “post cut” support plan that includes establishing a “help desk” and identifying a problem reporting process and resolution team.

If there is a “kick off” meeting there should also be a project close and review meeting.    This is where we can review what happen and how to transition the project to a support mode.   There should be an “as built” documentation package that is handed off from the project team to the operations team.  These documents will be outdated in less than a month, but it makes ongoing support viable if we have a record of changes to date, so make the extra effort to get this package completed as part of your project plan.   Ultimately you will want to have a 30 day review.   Keeping a client takes as much effort as getting a new client, so make ongoing client contact and system optimization part of your service offering.   Include ongoing training and you should be able to keep a client for life!

Hosted “virtual” phone system or own your own?

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!

3CX a Contender along with ShoreTel and CISCO For the SMB!

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!

ShoreTel SIP trunks using Asterisk?

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……

The iPhone 4S Battery Drain Mystery!

My brother came from New York to visit with me in San Diego over the Thanksgiving Holiday.  During his visit, he was frustrated by the fact that his brand new iPhone 4s battery could not last through the day!

I did not pay to much attention to his ranting on this subject, but during his 10 day visit, his iPhone battery charge never lasted more than half the day before it was a dead as a stone.     For the Christmas holidays I traveled to New York from San Diego.   During the first day, I noticed that phone had shut off because the batter had gone dead.   Never having experienced that before and, owing to the fact that I have my iPhone 4s wrapped in a case that has an expansion battery pack built in, I concluded that I must have forgotten to charge it over night.

That night I made sure to charge both the iPhone and the external battery case.  Next day, not half way through lunch, I noted my iPhone had gone dead again, burning through both the internal battery and the external battery?   WTF?   My brother started laughing as I now knew exactly what he was talking about during his visit to the left coast.   In my line of work (VoIP Tech Support), being without a cell phone is stress inducing to say the least!  I set about trying to figure out what was different and why my phone could not last a day before running out of battery juice?

What made this all the more interesting was the fact that I travel with an iPad2 as well?  Both devices have the same IOS level? My iPad was also a 3G model, so I concluded that AT&T roaming was not the issue.  After all, would it not effect both devices the same if the issue was related to roaming on the 3G network?  It must be something different about the two devices?   I then set about turning off everything I could think of in the iPhone.   I turned of the most obvious drain, Siri!   I turned off all notifications?  I turned off all the location based applications (so much for running up points on foursquare)! I even turned off the GPS and Bluetooth!

Nothing seemed to work?  I benched marked my iPad2 against my iPhone 4s.  The iPhone battery would be dead in less than a single day.  The iPad with all the applications on, that I had switched off in the iPhone, ran for two days before needing a battery charge.  My wife, who had my hand me down previous iPhone 3G did not have the problem.   The issue seemed to be specific to the iPhone 4s! The iPhone 4s battery gauge looked like the gas tank indicator on a Ferrari, moving from F to E in record time.   Maybe it was 3G data when no WiFi was available?  Nope, I turned that off, even though I did not have to do it with my iPad.   Email notifications were set to manual?

I began to scoure the Internet and could not find a single solution, though I found a recurring theme.  Apparently, when you travel with an iPhone 4s, especially outside of the US, this basttery strangeness is a real issue for everyone.   I can find no statement from Apple on this subject thought the forums seem to be filled with people sharing the same experience.   I am particularly certain it is unique to the iPhone 4s as my iPad did not have the problem nor did the older iPhone 3G?

Magically, on return to San Diego my home turf, the problem just went away.  My battery lasts the entire day with all the applicaitons, notification, Gmaill, Siri and GPS turned on!   Migrating Alpha Pariticles?   I know I am not the only peron to have this experience, so come on Apple, what is the story?

ShoreTel SIP Trunks a Snap with Ingate SIParator!

I don’t think your average business professional wakes up in the morning and says “Gee, I need some SIP”!   They do however ask questions like how do we get an Area Code from New York to appear on our System in San Diego?  Do I really have to buy 23 channels of voice on a PRI when I only use about 12 channels max?  Can’t we just “burst” up to 23 or 50 channels when we need them?   Can we have our phone calls re-routed to our branch office, if something happens to our main location?   These are market drivers that are encouraging businesses of all sizes to consider implementing SIP trunks.

What is a SIP trunk?  If you mention a T1 to a telephone guy,  he will think you are looking for a channelized voice path to the telephone company.  Ask an IT guy the same question and he will think you are talking about a 1.5MB connection to the internet!   Now bring an integrated T1 into the conversation and things get a bit more interesting.  Ask about a SIP trunk and you may get both of them scratching there heads.  If you are not working SIP trunk integration today, you most certainly will be doing so in the very near future!

To over simplify for purposes of discussion, a SIP trunk brings “dial tone” to your phone system over an Internet connection.    In most PBX systems, the connection to the phone company has been through a traditional TDM interface.  In a ShoreTel PBX, for example, you would come from the phone company provided “smart jack” to an SGT1K.  You would then use the Shoreware Director to configure the parameters that make a vanilla T1 a Primary Rate interface  like defining  the CO Switch type  (e.g. NI2, ESS5, DMS100), framing and signaling.

In a traditional TDM deployment, the separation of the PBX system from the Telephone Company is clear and unambiguous.  In fact, you often trouble shoot analog telephone  lines by going to the 66 punch down block, known in the industry as the “D Mark”  and remove the bridging clips that connect the phone company with the customers phone equipment.    In this way you can easily determine which side of the block has the problem.   With SIP there si a new challenge:  how do you separate the customer premise equipment from the telephone company provided network connection?    Where does your network end and the telephone companies network begin?

As we add SIP trunks to our network, the border of our network can easily disappear.   For this reason, we need to introduce a “enterprise edge border controller”!  The Border Controller is an essential element in provisioning a SIP trunk and is generally a dedicated appliance that provides a range of functionality that includes  NAT traversal, Security, Port management, Normalization, Call routing  and most importantly it acts as a “D mark” for your network, setting up a B2BUA between your iPBX and  your border controller; and between your border controller and your ITSP.    In this way you can think of your Border Controller as logical equivalent to a a 66 Block!

Why not use a Firewall to manage SP?   Clearly, if you are connecting your phone system to the Internet, there needs to be a “firewall” function.   A SIP RTP media stream is basically your phone conversation and it will take place over a 1000 different firewall ports.  Clearly nobody is going to open 1000 ports in a firewall or you might as well not have a firewall!  So a key functional requirement  for a  SIP trunk implementation  is the ability to track legitimate requests to open a port and then to close it when the session is over.   Firewalls that are “SIP capable” have this ability and are the minimum requirement for establishing SIP trunks on a phone system.

There are other equally critical functions that you must have in place for SIP trunking that exceed the ability of a Firewall and are more appropriately handled by a Border Controller.   “Normalization” for example, enables the appliance to provide language translation.    Like English or any other language, SIP sessions have  “dialects” and ShoreTel SIP might be different than SIP from Level3, Net Solutions or Paetec.    The Border Controller can mediate these difference enabling interoperability between these systems.

Two of the most widely deployed Border Controllers in the market are the CISCO CUBE  and the Ingate SIParator.  Both are excellent solutions, offering the required functionality to securely enable SIP trunking, including NAT traversal, Normalization and Security.    If you are integrating SIP Trunks with a ShoreTel iPBX, you will be very pleased with the Ingate “SIPParator” solution.  The Ingate solution  “Start-up” tool that is designed to get your up and running as quickly and as painlessly as possible.   If you  know the basic configuration parameters of your  ShoreTel and ITSP, the start up tool is the shortest possible path to your first SIP phone call from a ShoreTel iPBX.  Using the start-up tool you can quickly configure the basics, sanity test the basic configuration, upload it and then use  the Ingate  Web based Administration portal can then be used to further your configuration, logging,  reporting, monitoring and trouble shooting.    The SIParator  has been tested with a long list of SIP carriers and has many of the ShoreTel required parameters per-configured.    The support team at Ingate is both knowledgeable, patient and committed to making your ShoreTel deployment a success.

It is time to start integrating SIP solutions

Unified communications and its vulnerabilities

Unified communications is a revolutionary technology that integrates many worlds of communication at one place. The way unified communications has converged many services is something unprecedented. You can get all the great features of unified communication like instant messaging, video conferencing, data sharing, electronic whiteboards, and call controls etc through one service. Recent developments in the VoIP industry have made it possible to integrate VoIP with the unified communications. Key VoIP service providers like Packet 8, Axvoice, and Nextiva have already integrated unified communications in their phone services. One unique advantage of integrating unified communications is that you can access them through different devices. A key benefit of unified communications is that the end-user can respond to any type of incoming communication within no time. You will also be able to view one type of communication on a different type of device originally received on another device in a different data format.

Vulnerabilities of Unified Communications

Unified communications are vulnerable to different types of attacks. Let us review these threats which can exploit the weakness of unified communications.

Denial of Service Attack

This is one of the most commonly used ways of attacking unified communications. The attacker can use different attacking techniques to target the end user or even the servers involved in carrying out the whole process. The attacker usually uses SIP messages for the denial of service attack. The attacker waits for an incoming call to a phone user. Once the INVITE has been received by the end user, the attacker immediately sends the cancellation request. Resultantly, an error is generated by the invitee’s device and the call is ended. The main purpose of this attack is usually to disrupt the service. If the end user receives these kinds of calls repeatedly, the unified communication environment can direct the calls to other routes like email, voicemail, message store etc. The other dangerous type of denial of service attack occurs when the dialog is initiated between the two users. The end result is the BYE attack in which the call ends before it starts. This attack is also geared towards disruption of the service.

These both kinds of denial of service attacks can be overcome by a well designed SIP device. An intelligently built SIP device should be able to recognize if a CANCEL or BYE request is initiated by the end user or not. In the same way a private network directed through the UCS is not normally vulnerable to this kind of attack.

Eavesdropping

One of the key features of unified communications is that the end user can send the other user a RE-INVITE in the middle of a conversation for changing the type of communication. This RE-INVITE could also mean change in the location of the conversation. In this change of location, during the RE-INVITE, the attacker many invite someone else to join the conversation as well. The best way for the end user to shield himself from this kind of attacks is to only accept these kinds of invitations from the user who he really trusts. End user is strictly prohibited to send extremely confidential information like credit card number, passport number and other personally identifiable information unless very sure about the intent of the user at the other end.

Message hijacking

This is one other dangerous attack on the end-user. In this particular type of attack all the messages that are sent to the attack are re-sent to some undesirable user or users. The messages may contain very important information like meeting dates, critical document drafts, or other sensitive data. Only share this kind of information through secured means and only with known trusted users at the other end.

Prevention measures

Usually advanced unified communication systems implement a proper authentication system before enabling end to end communication. There needs to be a secure connection between the client and the server by matching the exact security protocols supported by each one of them. Encryption of the communications is one way of ensuring the security of the data travelling between two mediums. Secondly, all devices that are requesting authentication with the unified communication systems first need to be properly and clearly identified before any such permission is granted. A SIP aware firewall installed can also be deployed which can evaluate the SIP headers to ensure their compliance with RFC. Lastly standard techniques should be deployed to protect email servers, voicemail servers, and gateways which are critical to the unified communication environment security.


This was a guest contributed article. Create a FREE account to submit your article today.
Author: Robert Showerma

Setting up Microsoft Windows 2008 R2 Server for ShoreTel

ShoreTel currently runs on Microsoft Servers.   There are a number of Windows components that need to be installed to support the deployment.  If you have been installing ShoreTel for any period of time you already know that  FTP and SMTP services  along with Microsoft Windows ASP.NET, IIS and certain of its components are also required including Active Server Pages and Server Side Includes.  I also recommend that you get HyperTerminal, or better Putty to support SSL connections to ShoreTel switches loaded on your HQ server.    I find SQLyog to be an effective trouble shooting tool, so I also get that on the HQ desktop.  Having Adobe available will enable you to read the online documentation that ShoreTel provides.    If you are new to Microsoft 2008 servers the process for loading Windows Components is a bit different, so this silent video clip will walk you through the process.

Enabling Chat on your Website with ShoreTel ECC 7

When someone is on your website, it is like they entered your store. Clearly, they have an interest in what you are about or they would not be there. It is at this moment that they are most receptive to learning about your product and services. Would you not like to know when someone hits your website? Better yet, would you like an opportunity to interact with a visitor to your website? If so, you want to enable a CHAT function, a link that says “connect with a company representative now”! Clicking that link opens a real time conversation channel with an internal human resource at your company! Research proves that the sales conversion rate on these transactions are without equal. Do you suffer from “shopping cart” abandonment? Maybe that last minute question could have been answered if your site had a Shoretel Chat function!

ShoreTel ECC 7 Website Chat

Contact Centers are different that call centers in just that way. In a contact center we know that people interact not just by phone, but by email and web interactions like Shoretel Chat. If you are running even a small contact center, you need to experience the high impact customer development strategy of enabling Chat on your website. The application is relatively straight forward, especially if you have a contact center operation. It is hard to find a company today that does not have some kind of web presence, so why not integrate the two?

The ShoreTel Enteprise Contact Center has a real time ShoreTel Chat function. Visitors to your online store can click on a link that immediately opens a chat window with the next available Agent. The same rules and options that govern your handling of an inbound voice call, can be applied to a Chat session. Chat sessions can be “queued” for the next available agent and will even show up on the Supervisors display as a customer waiting for service!

ShoreTel Website Chat Doesn’t end here

The transcript of a Chat session can be automagically emailed to the website visitor, and a copy can also be sent to the contact center for archive. Chat sessions are presented to your Agents in manner that is consistent with the behavior they employ on a voice call. They see the Chat session “ringing” in on their tool bar, click answer and a browser window opens up and they can are now in a real time Chat session with a visitor out on the world wide web. Agents can select from per-authored files and screen of information that can be sent through the Chat session with a mouse click.

Chat is among the most valuable customer interaction tools that you can add to your arsenal of sales aids. It can often mean filling a shopping cart that might have otherwise been abandoned! The film clip give you an overview of how to implement Chat using the ShoreTel Contact Center!

 

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

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.