V14 Configuring ShoreTel SIP Trunks P2 -SonicWall or InGate SBC?

A question that keeps coming up in the support ticket system is the subject of InGate and Session Border Controllers.  Folks want to know if you need a SBC to configure a SIP trunk.  Why not just use a Firewall?  Can you configure ShoreTel SIP trunks to work without a SBC?  The simple answer is “yes” but the smart answer is “no”.  In our humble opinion, just because you can do it, does not mean you should do it!   Session Border controllers, like those offered by Intuit for ShoreTel,  provide functionality not normally found on a firewall.   “Normalization” for example, the ability to mediate ShoreTel SIP and your carrier’s  SIP, as they most likely speak a different “dialect” of the common language SIP, is not a standard firewall feature.

Application Level Gateways, sometimes take actions that are injurious to SIP messages.  Remember, SIP was not designed for NAT based networks.   Something has to keep track of which internal private trusted network users made a SIP request for service to another IP address across an untrusted boundary!  Which RTP (voice, video or “media”) ports need to be opened to support this request?  SBC can do this more effectively than firewalls. At the end of the day, you end up turning off the SIP ALG functions in your firewall to make it work! (In SonicWall turn off  “consistent NAT” and “SIP transformations”.)

We have never recommended bringing your SIP services into your VoIP deployment over the same circuit as your Internet circuit, but so be it.   At least, let’s use a separate IP address and make use of the DMZ port on your firewall, if you are not going to use a separate circuit!  Let us try to keep the SIP traffic from undergoing the same port specific inspections you put the Internet traffic on!  Again our best practice recommendation for ShoreTel, if you are serious about SIP trunks as the main Communications link for your company, is get an Intuit SBC and bring your service in on a separate circuit or IP!

SonicWall has for sometime, had a number of “service objects” to support the ShoreTel MGCP phones.  In fact, before SIP was enabled on ShoreTel, all media flowed on port 5004 which was really great for enabling transport level QoS!   Though there is a steady trend to use TLS and get both SIP messages and RTP over a single port, most SIP carriers expect to send messages on UDP 5060.   So if you are using a SonicWall, you will need to create new Service Objects, and put them in new Service Groups to get SIP to work.   You will need to configure Network Objects for your ShoreTel SIP proxy and configure access rules.  We recommend you also create a network object for your ITSP rather than enabling  an open 5060 for all the script kiddies running SipVicious!

We will do this again on a  CISCO ASA 5505 just for giggles as we get a lot of requests for that as well!  At the end of the day, however, for a serious business application of SIP trunks on ShoreTel, get a separate circuit and invest in an Ingate SBC!  Heck, you can even get a virtualized version of InGate!

V14 Trouble Shooting ShoreTel SIP

ShoreTel SIP is just not that hard to configure! When things go right, and it all works, it is relatively painless and very easy.   When things don’t work however, you will need to sort out the problem and figure out how to make it work.   The good news is that SIP is a clear text, english like “requests” and “response” message exchange that, once understood can be relatively easy to work with.   Using packet capture tools like Wireshark can be a real assist.   ShoreTel has built “remote packet capture”  into the V14 diagnostic portal and makes debugging sip issues even more easy to digest.

The message exchange for SIP “extensions” is not much different than that for SIP “trunks”.   So to learn SIP why not study a successful SIP connection first, before diving into a debug session.  What we have tried to do in this tech tip, is to illustrate the process of a SIP extension registering with a ShoreTel proxy server.   We picked a configuration that is comparatively complex, but not unlike one that you might find in the real world.  SIP extensions can unit remote office workers into a seamless call handling workgroup.  As such your remote worker will traverse a couple of firewalls and routers on its way to the SIP proxy.

In this configuration we register a SIP soft phone, remotely from the ShoreTel HQ site, over a site to site VPN tunnel.    The VPN tunnel is between a CISCO ASA and a SonicWall TZ250.  We note that 90% of the SIP issues we see having nothing to do with the configuration of the ShoreTel equipment and everything to do with the network devices, routers, switches and firewalls that are part of the SIP solution.  Small business solutions, for example,  tend to bring the SIP trunks into the phone system over the same connection they bring in their internet connection.  This means the SIP trunk is passing through the firewall, another most likely candidate for inducing a SIP failure.

This tech tip walks you through a successful SIP registration of a remote soft phone.  In our next tech tip, we will walk you through configuring a SIP trunk through a SonicWall and then look at fixing some broken SIP connections!

A ShoreTel Workgroup is a Contact Center for the rest of us!

We have been working around the call center space for a long time.  Actually, it is our first love! Does everyone need a full blown Contact Center?   If you have a real boiler room operation, with shifts of agents that are heavily manged, counted, recorded, measured complete with staff forecasting and multiple channels of client communication, yes you need an Enterprise Contact Center.   As Arlo Guthrie might say “what about the rest of us”?   The small to medium size business that is really not cracking the whip on customer service agents, but making efficient use of “knowledge workers” who often participate within a group setting.  How do we organize customer calls to this group?

A techncial support group or an order entry group might be a good example.   By grouping these folks into a “workgroup” we can funnel calls to them in a call center like fashion without the call center overhead of application servers and third party middle ware.   ShoreTel has an embedded call center like feature aptly named “WorkGroups” that is an ideal solution for this environment.   You can organize a group, route calls to group members and even queue the call until a group member becomes available.   While callers are in queue, you can organize the messages they hear, the time they wait between care messages and you can also provide “bail out” options at each step of the way.

The workgroup can be reached as a menu selection off of an automated attendant or have a phone number assigned that enables outsiders to call directly to the workgroup!   The workgroup can have an operating schedule applied that routes callers to alternative answer points if the group should be reached after hours.  Group members can Log in and Log out of the workgroup using their ShoreTel Communicator and still maintain their personal extension number and mailbox.  While logged into the workgroup, they can share the group voice mail box and see callers waiting in queue!  Supervisors can monitor the callers in queue and manipulate resources to meet call demand.   Reporting statistics on the group are maintained and easily obtained by the workgroup supervisor or administrator with reporting permissions.

We are now even making it possible for Callers to TEXT into your workgroup!  Group members can even email back a TEXT message!

The ShoreTel Workgroup strategy is a powerful call center like functionality and very cost effective.    The marginal cost of adding agent and supervisors license when you plan to implement a ShoreTel iPBX when compared to adding a complete Enterprise Contact Center is amazingly low!   We would be happy to explain the difference between a Workgroup and the ECC, so just contact us for details!

TEXT the keyword “workgroup” along with your name or email to 702-956-8700 and we will respond immediately!

 

 

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.

 

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!

Can I text your Enterprise Contact Center?

Phone only ‘call centers’ have been rapidly replaced with ‘contact centers’ that can also handle email and chat communications.  Customers want more options for interacting with companies they buy products and services from.  Chat requires the customer to be at a computer and though email may be sent from a mobile phone, generally the sender is at a desktop.    In a wireless world in which every man, woman and child seems to wonder around with a ‘text’  or sms enabled device on their person, does it not make sense that they would want to text your call center?

Most call centers seem to be comfortable adding more and more incoming telephone lines, but never seem to add more agents?  We now queue up more clients to the same number of agents and expect that our customer satisfaction scores will increase with each new telephone line we add.   Chat and email increase the options that an agent can use to communicate with a customer, but only text offers location independent immediacy and the highest level of accuracy in CRM integrations.

A text will be read, on the average, within 10 seconds of its arrival.  It has a significantly higher read rate than email.  It is considered spam free, as you must opt in from you own mobile phone to receive future text messages.  As most folks under 30 do not even have a land line, using the CID of a SMS text will yield a much higher accuracy rate when doing screen pops from CRM integrations.    Self Service options for SMS are enormous and scheduling an agent call back could not be any easier!

What would you rather do: call into a contact center, listen to the obligatory menu of options, self navigate to the customer service group and then hear the first queue message: “the next available agent will be with you momentarily”; or send a SMS text message directly to the contact center group, by passing the automated attendant  and if you do not receive an immediate call back, receiving a confirmation text that an agent will call you at your mobile number in four minutes?

We have created a website to enable you to immediately setup a text based marketing campaign! You can create an account at our TEXT PORTAL  and select a phone number for your campaign and be in the digital marketing world in minutes.  We give you free SMS credits when you activate your account!  Interested in extending this capability to your Contact Center?  We can implement text functionality to your ShoreTel Contact Center or CISCO UCCX in a matter of hours!

Contact DrVoIP@DrVoIP.com or send the word CALLME to 603-426-3253 for sample application!  If you would like to test T2E (Text to Email) text your email address to the same number and we will set you up. – DrVoIP

ShoreTel iPBX phone system Training!

Phone Training is a double edged sword.   Everyone wants it  but nobody really wants to make the time commitment required to get comfortable with the new phone features that a system like ShoreTel brings to your  business.   Most folks figure it is a phone, how complex can it be?   That is true, ShoreTel phone are easy to manipulate and most features are intuitive.   There are however, a range of features that improve customer care, increase availability and enable you to achieve priority call management that are new concepts in business communications.   These features deserve some attention and the hour or so invested in learning about call handling modes, primary phones, simultaneous ring, follow me and custom call routing enjoy more than favorable return on time invested.

In addition to basic user training (we have to find another word to replace user, sounds like drug addict) ShoreTel has applications that also require training.  For example if you have an Enterprise Contact Center or a Work group environment, you will need to provide instruction for your Agents and Supervisors.    Are you using CRM connectors like Salesforce and Microsoft?  Do you have a custom application integrated with your ShoreTel?  Maybe the Recording or 911 application?   How about the Mobility server?   Are you using the iPhone and android aps?  Finally, all of these system need an educated System Administrator to handle adds moves and changes, who is going to provide that training?

When it comes to the basic ShoreTel phone system,  typically we break user training into basic phone handling and save the Communicator as a separate session.   Not everyone needs to learn Communicator, but everyone in the enterprise needs to know the basics phone function if they are going to be effective come “go live”.   How to setup your voice mail, assign your extension, manage multiple calls, transfer, conference and park are essential tricks that all employes should learn.   Generally, this is a 30-45 minute session and groups of 10 people around five handsets with an instructor using a projector for the call manager is a minimum training environment.  Like wise, to get through the Communicator, it will take another 45 minutes.   If you have to train several hundred people, over multiple sites, training is going to be a significant time investment and several days of Per Diem for an instructor on site!

We have found that web based training can be very effective for all of the various types of users that need to better understand these systems.    You can do large groups and a much lower cost without sacrificing the informational content.  Though we find mufti-media self paced training resources to be a very valuable as refrenece material or to help future new team members get up to speed, it is generally agreed that having an insturctor led webinar is a better solution.   The instructor can be aware of the specific configurations that uniquely define every deployment and can answer questions, propose feature solutions and generally help folks better understand the rich library of features they are about to make use of.  System Administration is without question easily done by web, as you are just going to log into a Shareware Director portal anyway!   No need for everyone to hurdle in the server room!

We can help you with distance learning solutions (or come on site) custom tailored to you deployment.  We can cover the full range of ShoreTel products and generally enjoy helping folks!   Give us call or  Text “ShowMe” to 15165197813 and we will setup a meet!

 

 

 

 

 

 

AWS S3 – a ShoreTel backup strategy!

Amazon Web Services (AWS) has a range of storage options that make them our first choice in cloud based storage solutions and an ideal location for our ShoreTel data backup. In fact, now that ShoreTel has moved to virtualized hardware for voice gateways, we have moved our entire ShoreTel deployment into the AWS EC2 environment, but that is the subject of a separate blog! AWS is an ideal solution for backing up your ShoreTel configuration. You can choose to back up to the Glacier storage service if you can stand a few hours of down time retrieving the backup files, but S3 (simple, scalable, storage) is the best solution for setting up a shared network drive to faciliate your ShoreTel Server backups.

Backups should be a regular part of your IT hygene and should automate the process of securing data offsite. Enabling AWS S3 is a very simple, cost effective and can be fully automated. You can also take advantage of other AWS services like SNS push notification services to send verificaiton and administration alerts. Given the global foot print of AWS, the growing base of AWS data and availability centers, even your backup solution can have a backup solution! AWS is an infrastructure as a service so you will still need to manage the process.  The provide facilities, but you share responsbility. For example, you wil need to find a client side solution to enable your backup. You can use an AWS provided sample API if you want to write an interface into an exsiting backup solution but most deployments can more than benefit with a simple software solution installed directly on your ShoreTel server. We recommend either the TntDrive or the Cloudberry solution, both are excellent and even have freeware and trial versions!

Opening an AWS account is very easy to accomplish and if you already have an Amazon book buying account you are already good to go! Just log into AWS, bring up the menu page and select S3 from the storage and content delivery options. It will take about two minutes to create a an S3 “bucket” and apply then apply a security profile! You will need to note your identity and security keys as they are used to “log into” your new bucket. Once the bucket is created, you can then go to your ShoreTel server and establish a shared drive using one of the client side solutions like TntDrive or Cloudberry.  (You might also want to check out the comparison of other backup solutions for Mac based computers).

The ShoreTel Data file still contains all the information you need to rebuild your system from a bare metal server and you can also make use of the ShoreTel provided backup scripts to further assist your efforts. Our standard best practice is to include AWS cloud backup as part of our ShoreTel support agreements for all DrVoIP clients so there is no reason for any company, regardless of size, not to have a current backup of their ShoreTel deployment safely stored off line!

DrVoIP will provide free ShoreTel backup for any ShoreTel system owner that asks us to do so! The DrVoIP Video walks you through the process of setting up backup using AWS S3, from bucket creation to client side install!