ShoreTel SIP Trunk Configuration – Version 14 update Part 1

Our older posts on this subject are getting a bit dated and an update is long over due.   ShoreTel has been using a version of SIP since day one.  We say a version of SIP because at the formation of ShoreTel, SIP standards had not yet been solidified.   ShoreTel SIP, therefor, was not interoperable nor did it need to be.   Our fist experience with ShoreTel was Version 3.1  back in 2001!    At that time, ShoreTel did not yet support IP phones, but ShoreTel SIP was and continues to be the call setup protocol used between ShoreGear switches.

Though ShoreTel introduced IP Phones in Version 4 with the private labeling of Polycom handsets, ShoreTel SIP for desktop devices did not become available until Version 8.   This early version of the SIP protocol required you to configure the first version of the IP8000 as a SIP trunk not a SIP Extension.  It was a step in the right direction, but it was not until V13 that we got a version that was more compatible with other SIP devices and not until Version 14 before we reached PRI parity on SIP trunks with the introduction of media termination points.

SIP in general is relatively simple to configure and mirrors most of the steps you take to implement a normal TDM Trunk Group.   The devil, however is in the details!  IP profiles, NAT, firewall, Digest Authentication and Carrier particulars need to be mapped out.   Generally, a Session Border Controller is a best practice for a SIP deployment.  Where does your network end and the carrier network begin?  Well, that is the single most important benefit of a SBC!  Additionally, the SBC can be the point at which we “normalize” SIP messages and translate between any dialectic differences between SIP implementations.

Generally, in ShoreTel you will setup your underlying resources by allocating ShoreGear switch ports, media  termination points, profiles, timers and DTMF handling configurations.  The  Creation of a SIP trunk group is very similar to the configuration of a PRI trunk group and the same options will need to be specified as to the use of this group.   Then SIP trunks are added to the SIP trunk group, the actual circuits on which phone calls will take place.   If the trunk group is to support tandem trunking and is connecting to another system as a tie line, the off premise extensions and digit translation options will also need to be configured.

The first video will walk through the configuration of a TIE trunk between two ShoreTel systems.  One system will use the TIE trunk to place all outbound PSTN phone calls through the other ShoreTel system.  Both systems will use the Trunk Group for extension to extension calling, with one system having extensions in the range of 200-299 and the other having extension in the 300-399 range.   We will walk through the basic configuration and then also take a look at wireshark captures to illustrate the SIP call setup message exchange.    In the second part of this update, we will the route calls out a SIP trunk to a SIP carrier for PSTN calls, using several different SBC’s.

Contact DrVoIP@DrVoIP.com to have us setup this up for you!  We offer flat rate configurations!

 

ShoreTel fail over options using Vmware – Part 3 the “HA” and “FT” Option!

A quick review of vocabulary before we go into this subject any further.    First when we refer to vSphere, we are talking about the entire VMware ecosystem and all of its components.   It is just a short hand for the entire system solution.    ESXi is a VMware hypervisor.  It is the “host” hardware on which the “guest” virtual machines run on.  vCenter is an administrative portal that enables you to manage multiple Datacenters.   A Datacenter is a collection of ESXi hosts.  I strongly urge all serious engineers to watch Kieth Barker’s presentation in CBTnuggets on this subject, particularly his presentation on HA and FT in the certification training for vSphere VCP5-DCV.  Kieth is a truly excellent instructor and he gets paid to make videos!

A more advanced ( read cost more money) strategy for managing server failures in vSphere is either High Availability or Fault Tolerance.    Assuming we have three ESXi hosts, lets take a quick look at how each of these strategies would work.   Using vCenter we would enable High Availability or HQ at the cluster level.  The first ESXi host to boot up, would be nominated Master. Assume the ShoreTel HQ is a virtual server running on this ESXi(1).  All the ESXi hosts in the cluster, would exchange heart beats over the management LAN that they all share.   Should the heart beat from ESXi(1) not be detected, it would be considered down and the virtual machine would be restarted on the secondary server in that cluster.

An VMware server running VMware Tools, can also generate heart beats between itself and the ESXi host that it is running on.   Should the host not receive a hear beat from the guest VMware server, it would consider it down and cause a new instanc of that VM to run.   Generally, it is a good practice to use a backup hearbeat to verify the failure of a machine.  For example, if the host machine does not generate a heart beat detected by the other hosts in the cluster a back up check could be made to see if the iSCSI storage is being accessed by the missing VMware server.  If that heart beat is detected, then the guest is not considered down, but is consider “isolated” and the new instance will not be started.

The issue with High Availability is how long does it take to bring up the replacement guest machine on a new ESXi host?   What is the boot time?   In Part 2 of this discussion we talked about a configuration that could survive this issue if it was the DVM that went down as the HQ would take over during the down time.  If this was implemented in vSphere with HA, the entire process would be transparent to users.

Fault Tolerance is the solution when there can be no down time whatever  should the HQ server fail.    FT is activated through vCenter as easily as HA, but generates a “mirror” image host that is always running.    For example, a ShoreTel HQ server running as primary on ESXi(1) might have a “mirror” host running as a secondary on ESXi(2).   Should the primary ShoreTel HQ host fail, within microseconds the ShoreTel HQ mirror or secondary will take over.  Not only will it take over as primary, but a new secondary mirror could be started on ESXi(3)!

Clearly FT is the way to go if you feel you can not survive a ShoreTel HQ loss under any condition.  Understand that it is resource intensive, as you are minimally running twice the horsepower!  Also to keep the “mirror” images alike, you will need a high bandwidth connection between ESXi hosts to provide for “FT Logging” which is all the activity to copy real time between hosts.

As previously mentioned, a copy of VMware vSphere Essentials Kit which includes ESXi for a total of 6 processors or 3 severs with 2 processors each and a copy of vCenter along with updates for 1 year is about $560.  vSphere Essentials Enterprise Plus which adds in the functionality of vSphere Hypervisor, vMotion, Cross Switch vMotion, High Availability, Fault Tolerance, Data Protection, vShield Endpoint, vSphere Replication is $4229.   Support on all products can be purchase as needed or for term.

Out next project is to figure out how to do this all on Amazon Web Services and at what price!

The video shows key elements of this discussion!

 

ShoreTel fail over options using VMware – Part 2 the “Poor Man” Option!

A simple yet very effective step you can take to assure a high availability  is all but free!  It occurs to us that it is no longer acceptable to install ShoreTel on anything other than a VMware ESXi server!  Lets face it, you have to purchase a hardware package to host your server regardless of which way you go.   You have to purchase a copy of Microsoft Server, regardless of which way you go.  So how do we make this more cost effective?   From our perspective upgrade the hardware platform you have to purchase anyway,  to be a quad core with about 16 -32 GB of memory.  ESXi is still available for free, so download and install it on that platform then install the Microsoft Server on top of it!

Now you have your ShoreTel HQ server at the HQ site.  No harm no foul and you are positioned to do some really kool things.  First, clone the Microsoft Server and bring it up as a DVM.  The key here is to install the DVM at the same level as the HQ server, not below it as a child server.  Put you HQ users on this server and have this server manage all your HQ site ShoreGear switches.   The reason for this is, it is the cheapest most cost effect fail over you can provide.  ShoreTel servers fail up, OR across but not down. This means if the DVM fails, the HQ server will proxy for it for those users!  Forget all that Double Take Double Talk!  Just do it.

While you are at it, bring up a virtual ShoreGear User switch as a “spare” switch and also install the vConference switch. The spare switch enables you to spin up an alternative switch for any site, if a switch at a site goes down.  No cost to you unless you don’t fail bak in under 45 days! Why would you not do that?  Why would you work with a partner who did not just do this as a “best practice”.   Come on guys, this is like deployment 101,  just do it.  The freaking conference server is “free” as an IM solution and the licenses for the conference bridge and desktop sharing users is cost effective when compared to anything in the market including GoTomeeting and Webex!   Again, what is there to think about?

So now you have your VMware platform offering a HQ server, a fail over DVM server, User Switch and an IM server.   Consider that for the cost of a Microsoft Server (you saved that by cloning one, remember) you can purchase (hoepfully from us)  a copy of vmware Essentials.  This package adds vCenter to the mix and now you are kicking it.    vCenter sets up a centralized administration interface for your ESXi servers.  You can now setup heartbeats between the ESXi host and the VM machines as long as they are running VMware tools.   You can also run heartbeats between vCenter and the ESXi hosts so that on failure of a heartbeat, vCenter launches another instance of whatever serer went down on another cluster host!

Are you freaking kidding me?

The video shows you how to install the DVM at the same level as the HQ server and how to clone a virtual machine.  Subsequent videos will explore the high availability and Fault Tolerant options available with vCenter and clustered ESXi hosts.

 

WebRTC “peer to peer” Call Center Demo!

What is a “peer to peer” call center?  The concept is a fully functioning call center that exists only in the internet browser of the workgroup agents and supervisor participating.  In fact, no telephone lines are needed, beyond the published customer service number.  There is no large internal LAN network. No complex phone configuration, not eve n a handset. All communication with Agents is done through a Chrome or FireFox browser.  Your computer needs to have a microphone and be on the internet.  The microphone can be built in or be a USB based headset plugged into your computer. (Hey, here is an idea: Music on Hold is so last century, now we can have “video on hold”  show them a product demo)!
We created a demo at http://DrQOS.com (Dr Quality of Service, DrVoIP’s alter ego) that you can log into as username:agent1 with a password:test1234. The demo system has a fictitious company automated attendant and when you call the main number 619-717-2143 you will hear the FAKE menu and you should immediately press 1#. You will then be routed through to the logged in Agent. The agent is made ready by just logging into the portal. Click on answer and you will be connected and speaking through the webRTC protocol resident in your browser out to the caller (again remember only Chrome or Firefox browsers are supported).

NOTE – Please do not log in as the Agent and then call yourself through the Agent console, the demo is designed so you can see both sides.  You can be the agent or the caller, not both!   If there is no Agent logged in, the caller will be asked to leave a Voice Message.  In most Browsers the first time you click answer you will be prompted by the browser to grant access to your mic which you should allow!

 

2017 UPDATE – We have continue to develop the product and have taken down the above site.  It has now been replaced with a production ready solution built out on Twilio and AWS.   The product enables WebRTC as well as a variety of SMS services including text to email.  Please text the word DEMO to 424-348-4000 and we will set you up with a demo account.  Here is an overview of the product!

A ShoreTel Communicator for the Mac?

We recently had an opportunity to work with a ShoreTel client that was exclusively using Apple Mac’s throughout their enterprise.   We asked how they made that decision given the clear cost advantage WinTel PC hardware had over your basic Macbook.   The answer was simple and clearly economic.   They had used Windows in the past, but found that they had to many problems with virus, email, drivers and the annual cost of license renewals! Yes the Mac’s cost more but they just seem to work and they don’t have to worry license issues.    Interesting.

This was a ShoreTel deployment so that made for some interesting trade offs when it got down to the desktop software.   The ShoreTel Communicator is optimized for the Windows based machines.    There are several license types for Personal, Professional, Workgroup Agent, Workgroup Supervisor and Operator Communicators.   With the Mac, there is only one Communicator and it has the functionality of the ShoreTel Web Communicator which is basically a Personal Communicator.

It does however get the job done as far as call handling modes, inbound primary phone options, multiple call management and visual voice mail.  You can setup your call handling modes including your personal operator and find me functions for each mode.  You can configure and select 5 alternative phones and setup your incoming call routing to include simultaneous ringing of other phones.   The visual voice mail tab works just like you would expect and you can also select a history and call details tab.

The noticeable difference is the absence of IM options.  ShoreTel had been suggesting the use of iChat for that function as that client was supported on the ShoreTel SA-100/400 conference servers.   In the Communicator there is always more than one way to do something: point and click, right click, use some chord sequence on the keyboard that includes the control key.   Right clicking on a Mac Communicator however is not going to work!  There is however, drop down menu options that appear as required to assist your call management.   All in all, the Mac client is an excellent solution if you have a Mac and a ShoreTel.  You can download the MAC dmg installation file from the ShoreTel HQ server and you are good to go!

Find the password from behind the ********** and other security vulnerabilities!

If you are paying even the slightest attention to current technology trends, you will notice that many of your desktop applications are taking on the appearance of a browser!  The entire Microsoft Office suite, for example, has been optimized for the “cloud”.  Free versions available for iPhone.   Mobile devices in particular are depending more on “server” side applications with the “client” reduced to a thin client browser type interface.   The good news is that less computing power is needed at the desktop making the possibility of re purposing old computer as thin clients a reality.  No need to run out and get the latest hardware and desktop operating systems, if you are moving to the equivalent of Microsoft Office 365,  Google Docs or any of the increasingly popular cloud based solutions.

Along with the dependency on browser based applications is the alarming rate of security vulnerabilities that are exploit by the savvy against the less sophisticated user.   As the browser becomes more widely used as the primary application interface, more security violations are  experienced.  Why?  The best way to understand this phenomena is to look at a very simple example of a security vulnerability observable on most desktops, the cached Password.   When you bring up your browser to access your favorite cloud application, your user name and password are often presented automatically.  The Password field is generally filled with a string of ************ to block out your password from view.  Once you realize how easy it is to recover that Password and to display it in clear text, you will intuitively learn how dangerous cloud based security vulnerabilities can quickly become if not judiciously policed by an educated user population!