Recording ShoreTel phone calls!

Call Center not Required!

Long the standard in boiler room call center applications, recording calls is often a requirement outside the call center.    There are any number of reasons to record calls for including compliance, clarity and certainty and just management of customer quality service.   There are a variety of recording solutions in the market and they all have very different feature sets.  Do you need the ability to annotate calls?   To search on more complex parameters that time and date?     If an employee is being recorded and transfers that call to the HR Director of the company, should that segment of the call be recorded?   Do we want to record inbound calls only?  Both inbound and outbound?  Do you have multiple locations in your deployment?   Do employees have the right to start and stop recordings?  Add notes?  You will also have to consider how recording are to be stored and for how long?  This can have a huge impact on hardware requirements.   Just some of the characteristics you might want to consider as you look for for a recording solution.  The list of features is long and there are many options to chose from.   It is best to get a solid requirements document together and to make sure that you fully understand that recording alone is not all there is!

Recording Server Applications

ShoreTel has an optional recording function that can be very effective!   It can be installed as a single server solution or as a multiple server, multiple site solution.   It can record all calls, or just in one direction only.   You can select who is recorded and you can also select the archive location and time frame.   The solution is deployed on a ShoreTel server, either HQ or DVS depending on the deployment model.    There are actually four modules that can be installed: the recording server; the client side, the web player and the administrative module.   The solution uses the integrated recording functionality of the ShoreTel phone system and most of the usual user group and class of service settings apply.

Generally you will create a route point with a call stack as deep as the number of calls you want to simultaneously record, and put it on the server that will host the recording application.   You will also need a route point for the player and you will need to create a user who will proxy the recording functionality.   The server install is very simple and conforms to the usual point and click install expectations of a Windows server application.  The configuration is very simple, just provide the route point extension number, note the port for recording and click install!

The Administration Application

The Administrative application enables you to configure the specifics of the recording server and  to create profiles.  This application can be installed on the server or on a PC that can reach the server.   The configuration options are very easy to understand and simple to enter.  Basically they deal with where files should be stored and for how long.  You also have the option of either saving the recordings to a file system, or saving them as a voice message.


You then create profiles that are used to customize different groups of extensions.   For example, you might want persistent recording for some extensions and not others.   This means that the recording continues even if the call is transferred.  Do you want inbound and outbound recordings?   And exactly who should be recorded!  The profile also dictates if recordings are to be made all the time, or sampled as a percentage or by a defined schedule.

Client Side Options

The client side application is installed on a pc and is optional tray icon.   You would use this only if your profile enables users to start and stop recordings and to tag recordings.   If this is not a privileged that you want to extend to those be recorded there is no need to install this optional application at each desk.  The use of the client is profile dependent.


The Player Application

The last application defines the player and is very useful for visually managing recordings.  You can use a phone to play recordings , but most folks find this web application to be more useful.   The application must be installed on a server as it uses IIS, but the recordings are played locally on a windows machine that has a sound card!   Each extension is listed and there is a time and date stamp on the recording file.  You have the option of storing other file information, like ShoreTel call properties to enrich the identification of a recording.

ShoreTel Recording Player


All in all, the ShoreTel Recording Application is a sweet suite!  It gets the job done and at a price point that compares more than favorably with the third party Recording applications found in the market place.   We recommend it for both call center and general recording applications when you are on a ShoreTel iPBX!   Give us a call and we can help point you in the right direction or get this installed and configured for you!





Understanding ShoreTel Connect ECC Shifts!

Why use Shifts at all?

Most call centers have “on hours” and “off hours” that route callers to different options based on time of day and day of week.  ShoreTel ECC has a concept entitled SHIFTS.   Shifts have day types:  Weekday, Weekend and Holiday.    You  go to System Parameters in the Contact Center Director, then Schedules and the create a Shift.  Name the Shift something useful, specific the day type and the time the shift action should occur.   You then  apply it to the IRN you want to alter, open or close based on your shift schedule.   If you do not understand shifts, however  and how they are utilized by the ECC you are at risk of shutting down your call center unintentionally.

Let’s take a closer look at how Shifts work!

Each IRN in the ECC that uses Shifts, has a default setting that specifies where the call should route, if there is no corresponding shift instruction.    The Shift might specify a Script, Service or Device.  For example you might have Shift named “M-F”  defined for day type Weekdays that is active at 8:00AM and specifies that the call should be routed to a script for handling calls during “on hours”.    You might then also add another Shift named “Lunch” for a day type Weekdays and set if to activate at 11:59 AM and point it to script that plays an announcement alerting callers that the call center is closed for lunch and invites them to call back at 1PM (never happen but it makes for a good lesson example).    Now we create another Shift also named “M-F” for day type Weekday and set it to activate at 1PM.  This action points the calls back to the script for “on hours”.   Clearly, you also created a Shift for “M-F” for day types Weekday and set the action time at 5PM.   The action is to send the call to the script for After hours.   Make sense?   Seem easy?


Danger – The trouble Spot with Shifts!

Let’s assume you have an IRN for Sales and an IRN for Technical Support and you apply the shifts we defined above, to both IRN’s, but on the sales IRN they do not close for lunch!   For this reason, you do not apply the Shift entitled “Lunch” to the Sales IRN.   Let’s assume the default route for the Sales IRN is the Closes script, so that after hours calls defaul if not specified in the Shift list to the after hours call handling.   So what do you think will happen to the Sales IRN at 11:59?


The fact that you created a Shift and one now exists for “Lunch” during the week is the important take away.   Once you apply Shifts to an IRN, ALL shifts apply even if you did not apply that shift to your IRN.  In this simple example,  the Sales IRN will follow the Default route because you did not specific an alternative destination in you shift list on the Sales IRN for Lunch time.   The fact that the Shift exists in the ECC database, requires that you specify an action for that Shift!   This is where most folks get into trouble!

What Version of ECC is your Shift definition?

In versions before Connect and ECC 8,  Shifts required you to open and close a shift.  After version 8,  you are not required to close a shift but it would be a good practice to do so!  You must account for all shifts, even if they are to relevant to your IRN.   The only way around this is to NOT apply any Shifts to an IRN.  If the IRN does not use Shifts at all, it will ignore all Shifts!   A bit confusing but once you “get it”  it is easy.

When in Doubt press Explain Shifts!

In the IRN definition press “Explain Shift” and then select the day you want to explore.   The list will populate with all the Shifts that impact that IRN.   Remember it does not matter if it is on your list!  What matters is that the Shift exists for the ECC and you must specify an action, or in the absence of a direction, the default destination for that IRN will be followed!




TOP ShoreTel Connect Installation Gotcha’s !

So you are upgrading to ShoreTel Connect!  Watch out for these blistering hot spots:

Assume you have a call center that works three shifts, with 15 Agents per shift.  In the Pre-Connect world, you would define 45 agents but you would only need licenses for 15.  The Pre-Connect ECC license strategy was “concurrent users”.  The new license strategy requires you to license 45 Agents.  Additionally, all agents have to be named in the iPBX, costing you an additional “per seat” license for the newly named agents.  Before, 45 agents could log into extensions Agent1 through Agent15 using their AgentID to differentiate them for reporting purposes.   Wow!  I hope you don’t find this out the hard way.

Here are some of our favorite ShoreTel Gotcha’s:

1 – Ever have to move route points from one server to another?   You CAN NOT use the batch utility to do this and must remove and then reinstall each route point.   So much fun on a large contact center deployment ( If you know SQL you can actually modify the configuration database to do this).

2 – Want to change IP address of your HQ?   If you are using the new family of 400 phones, you will have to touch each phone individually and manually CLEAR the Configuration for the new Option 156 and DHCP values to take hold.  How would you like to upgrade 3K phones across five times zones to learn that gem!

3 – Gee, would it not be nice to use DNS Name resolution in the Phone Setup?  You could just change the IP address in DNS and update your entire deployment!

4 – Is it no time to get rid of the DB9 Serial IO cable for switch configuration?  It is the 21st century and we sill do not have USB on ShoreTel switches?  When was the last time you had a serial printer cable with an DB9 connector hanging around your tool bag?

5 – Setting up OBDC connectors still use 32-bit connector and do NOT support AD login.   If you are connecting to Microsoft SQL, for example, if you use an AD credential your ECC Script will fail.

6 – Active Directory  integration is a one way sync out of the box.   Even adding the ShoreTel professional Service add on for AD will not solve all your issues!

7 – ECC Shifts will destroy you if you do not fully understand their use and impact.   Create a Shift to close on of your Customer Service Queues at 1PM and end up closing your entire call center!  (See this Blog entry).

8- You can not enter anything in the External number field for transfer a call but  9+1+NPA- NXX-XXXX.  No 9+011-44-204-668-5000 for example.  It will not work! Not for a call handling mode, CTI route point, External Assignment.  Nada. no bueno, NFG!

Useful and Helpful Event Log error entries!  Our Personal favorite:


Send us your favorite Installation and Maintenance Gotcha’s and we will update the list and credit you for the contribution!



Add DNIS routing to your ShoreTel ECC Contact Center!

Why Route by DNIS?

Routing by the number the caller dialed, or DNIS is the preferred routing strategy for any Call Center call flow.  Clearly you can assign a DID phone number to a specific call flow and anyone who knocks on that door is answered by the same group of agents.   It is much more efficient to grab the DNIS information, however, and use it to index a database to retrieve the call routing information.  In this way, we only need one door to the call center!  The DNIS might be used to route a call to the proper product or service group and it may also be used to retrieve client information that the call center Agent needs to see displayed  in order to provide a custom care answer prompt.

Consider the requirements of a Hospital that is providing “centralized scheduling services” for 1000’s of primary care physicians.  When the inbound call is presented to the Agent, the requirement is that the caller be greeted with a customized answer prompt.  For Example:  “Doctor Leary’s office, are you calling to make an appointment?” or “Thank you for calling Doctor Williams”.  This type of dynamic call handling can best be managed by using DNIS information to retrieve the Doctor’s name from a database   We do this regularly in CISCO UCCX and ShoreTel ECC Call Center solutions and the process is essentially the same for both solutions.

ShoreTel ECC Route by DNIS example

First, we need to create a DNIS Map in the ShoreTel PBX; a ‘route point/IRN ‘ combination to pass the call to the ECC;  and an ODBC connector from the ECC server to your favorite SQL database server.   The SQL server would host the database your scripting application needs to access in order to obtain the correct answer prompt.  Lets assume that the database contains a very simple table structure:

DABASE = DNIS_listofDoctorsOffices = (Field1 = DNIS Number, Filed2 = OfficeName, Field3 = QUEUE_IRN)

You would then write a simple script to take the incoming DNIS information and use it to index the database and get the OfficeName and maybe the Customer Service Queue that handles that office (City or State or what have you).  There is no limit to the information you could retrieve and present to the Agent,  For example: Name, Service Class (Platnium, Gold or Silver), Renewal date, last order, shipment date, the list goes on.   In this simple example the script would take the DNIS and use a SQL expression to retrieve the answer prompt data:

Select * from DNISlistof DoctosOffices where DNIS = %DNIS_NAME%Sample ECC Script Screen

Creating a DNIS MAP in ShoreTel iPBX

In the ShoreTel iPBX Trunk Group it is necessary to create a DNIS map for two reasons:  First, the ShoreTel ECC can not read the DNIS directly, it requires the administrator to fill in the “dialed number” column in the DNIS map.  The ECC has a mandatory call profile filed named DNIS-NAME which will be auto filled with the information you provide in the DNIS map “dialed number” column.     Secondly, unlike a DID number that might be directly mapped to an extension, we need a way to get the incoming call connected to the IRN on the ECC that is running the DNIS SQL lookup  Script.   In this example, the Destination field of the DNIS Digit Map in the ShoreTel iPBX Truk Group points to the Route Point/IRN in the ECC that supports the script.



POPing the Agent Display with useful Data

The ShoreTel ECC has two variables data types: Mandatory or System Variables; and User create Variables.  The Mandatory variables are system call parameters like ANI or DNIS and a long list of other system based data.   ANI contains the digits that make up the caller identification and that is also often used to retrieve database information.   If you are using ANI you will need to do some string manipulation to strip off the +1 from the 10 digit number, or format to match your database.   User created variables are the name you create for the fields you will get from your database.  Useful examples would be CustomerName, DateOfService, AccountBalance and RenewalDate.    Any Variable, User created or System,  can be pushed out to the Agent Display within the ShoreTel Communicator.


What is your Call Center Application Requirement

We have seen it all, so we are always interested in your requirements for custom CRM integration and Call Flow management.  Give us call or drop us an email and play “stump the vendor”.   We would love the challenge of finding yet another new ShoreTel ECC or CISCO UCCX Contact Center application requirement!

[show_related ids=”2828, 2610 ,2447, 1378″]

Compare CISCO and ShoreTel “dial plans” and “calling priviledges”!

What is a route or dial plan?

Most if not all phone systems provide for route plans and calling or “class of service” privileges.   The dial plan defines the over all numbering system used through out the system.  For example, how many digits do we need to define all of our extension number or telephone endpoints?  What access code do we use to indicate we want an outside line?  What numbers will we set aside for system features like the automated attendant, voice mail, contact center and conference servers?   Generally this is one of the first decisions you make when designing a new phone system.   Once set, it is usually very cumbersome to alter or refine.

Calling privileges or “class of service” defines what facilities a specific user might have access to.   For example, we might want the Lobby and Kitchen phones to be able to dial 911 and make internal calls, but we might restrict them from dialing outside numbers at all, let alone long distance or international phone calls.   Some systems even restrict internal extensions from calling other internal extension numbers.  For example you might isolate the CEO from being dialed by the automated attendant “dial by name” directory and you certainly do not want the over head paging system accessible by an outside caller!

How do we include a new branch with the same internal Extension numbers?

These options become increasingly more complex as organizations redefine themselves as a result of a merger or acquisition.   How do you add that new branch office into the company phone system?  Things become even more exciting when the new office has a “dial plan” that uses the same internal extension numbers already in use by the HQ phone system.   ShoreTel and CISCO tackle this in very different ways and it is interesting to note the different strategies.

In ShoreTel you define you “dial plan” as the necessary first step in designing the phone system.  How many digits do we need to dial internal telephone numbers?  Out of the box, ShoreTel assumes you want to use three digit extension numbers.   You can change them to four, five or more digits but you can only do this once.  You can increase extension digit length but you can not reduce them, so plan carefully!  The next issue is what range will we use for extension numbers?  Will they start with 1, 2 or some other digit?  Don’t forget those “system extensions” as you will need them for many features and system resources.

ShoreTel also uses the concept of a User Group and a Class of Service.   A user group might be a function like Executive,  Manager, Employee and House phones.   The Class of service defines Telephone Features, Calling privileges and Mailbox options.   Telephone features might include who can access the Intercom, or record their own phone calls.   Calling privileges enable internal, local and long distance dialing options.  Finally mail box options indicate the size of messages, greetings and administrative controls.

ShoreTel has a very simple to implement and understand concept for dialing plans and calling privileges.  With simplicity, however, comes some restrictions.   Lets take the example of acquiring a new business unit and they have an existing dial plan that conflicts with the one already in place.   Well, you could through the inplace  phone system out and install ShoreTel at that location (certainly the ShoreTel re-sellers plan) by expanding the existing ShoreTel but that would certainly mean an change in extension numbers at the newly acquired business unit.  Optionally, you could install another ShoreTel system and integrate the two separate system through a SIP  tie-trunk.  Using a digit translation strategy you could let the other guys keep there old extension numbers but you would have two separate telephone systems, each with their own configuration database.   (In CISCO parlance that would be a two “cluster” solution).

ShoreTel Simple or CISCO Complex?

CISCO uses the concept of “route patterns” to define a dial plan.   It is a bit more complex, but with that complexity comes great flexibility.   A “route pattern” is a map for taking the digits a user dials and searching a database to find the route those digits should follow to complete the call.  For example, a user in the California Office might dial 9,1-212-523-51234 to reach extension 234 in the New York office.  The route pattern would then hit route list that might include a local PRI for a long distance call to NY, dropping the 9 and out dialing the E164 1+area code and number.  That route list might also include a WAN gateway that directly terminates in NY and in that case, drops all the digits but the 234 while placing the call over the company’s WAN connection.

To be fair, ShoreTel can also complete a call over the WAN and would be smart enough to know that #234 also has a DID number of 212-523-51234.  If the California user dialed #234, and the call could not be routed over the WAN, the call would be completed over the Long distance line using “PSTN fail over”.  The feature does not, however work the other way.  Had the user dialed the LD number and encountered  a network busy condition, it could not then route the call over the WAN.

As to”class of service”, CISCO uses the concept of a “partition” and a “calling search space” (i.e. CSS).   Though some folks like the “lock and key” metaphor,  we think the best way to understand this is to realize that “partitions” define who can call me.   “Calling Search Spaces” define who I can call.    So if my line or phone is in a CSS that specifies partitions NYPhones, SFPhones, UKPhones, Windstream, COX and Verizon, then those are the objects I can call.    If my device is in a partition named SFPhones and your CSS does not contain that Partition, then you can not call me.

Sounds a bit confusing, and at times it is.   The structure however enables us to build some very  significant solutions.  Take that example in which you have phones with the same extension number in two different business units in the same “cluster” or phone system.   You could put Extension 1234 in the NYPhones partition and in the SFPhones partition!   They would not conflict with each other!  Every phone, feature (i.e. intercom, conference), line in a CISCO deployment is in a specific “partition” and only reachable by an entity that has a Calling Search Space that includes that partition.  Simple!

Given that we are not in the business of selling phone system, only engineering and supporting them, We do not  have an emotional attachment to one over the other.  We observe that ShoreTel is best suited for smaller deployments and in fact can be easily deployed and managed by a small business of 25 or more.   Though there are larger ShoreTel deployments, we see them in the 100 – 1000 user line size most frequently.  CISCO has a low end Solutions, the Business Edition 6K-S for system under 150 users,  but the CISCO Collaboration solution could run a small a small country though the Business Edition 6K and 7K are optimized for 100 – 5000 users!

The video shows the two different approaches to solving these common route plan issues!







Trouble Shooting ShoreTel ECC Scripts

ShoreTel ECC Future?

The ShoreTel ECC or enterprise contact center is a remarkable product in many ways.   Though we are depressed to see that it has apparently taken a back seat to ShoreTel Connect as it relates to product enhancements, it remains a formidable player in the contact center space.   Clearly, if you are deploying a ShoreTel phone system, then it may be the only viable option.    We note that ShoreTel has made a new acquisition for contact center functionality in the cloud, so the potential of supporting ECC product enhancements may even be less hopeful as product development resources shift to the “cloud” and ShoreTel Connect.

Remember EasyRun?

We have worked with the ECC since before it was a ShoreTel product.  It actually originated as an OEM product, a re-branding  of a software solution brought to market by EasyRun, an Israeli based company founded by Avi Silber, long time VP of Software Development for Telrad.   ShoreTel ultimately executed a software source code licnese and the rest is history.  Unfortunately, we seem stalled at Version 9 of ECC, which was not a major evolutionary step from ECC Version 8.

At any rate, the product does a super job in small to medium sized Call Centers and meets the minimum daily adult requirement for call center functionality.   One particular  function enables the system to integrate with popular database solutions like Microsoft SQL.   This enables the system to take on some very sophisticated applications that include routing inbound calls based on the return of data in the customer service database.  One of them most asked questions of marketing professionals as it relates to Contact Centers:  “are all customers created equal”.   You might want to route an incoming call based on the callers status in your customer database as a Platinum client or as a deadbeat on credit hold.

SQL database dips are almost essential for any Contact Center offering.   ShoreTel enables this functionality through OBDC connectors to the host SQL server or CRM system.    One of the challenges for design and implementation engineers is testing the design and results of the SQL data dip.  Historically, ShoreTel has not provided a lot of debug tools here and documentation on inner workings of the ECC is not generally available.  If you are bold and go poking around in the BIN files, you will note a lot of exe files and if you are curious, brave and inquisitive you might take on an exploration of what these files are used for.

Undocumented ShoreTel Debuggers!

One file in particular seems to launch a very useful test tool.  We have never found any documentation on it, and it has become something of a legend among we ECC implementation engineers.   If you are fortunate enough to maintain a relationship with other engineers that share information, you can build up a library of useful tools based on shared results from others.  Kudu’s to one such brilliant engineer, Bill Fraedrich for sharing his growing list of FC_Thingy functions and the other members of the development community who regularly publish results.

Route Caller by ANI (caller ID)?

Recently we had to create a SQL data dip to pull back a customer record using Caller ID or ANI as the database index.   Now anybody who has done any Contact Center CRM integration regardless of vendor, knows that you have to do some string manipulations to strip off the +1 that will be passed by the carrier as part of the ANI information.   ShoreTel ECC, CISCO UCCX, it does not matter it is all relatively the same.   Once you clean up the ANI you can pass it off as part of a SELECT command and go get your data.  Then manipulate the data to find the fields you are looking for to make your routing determination.

The undocumented debugger!

The issue becomes how do debug a script that is not producing the results your design expected?  Again, ShoreTel comes up short here as it relates to documented debug tools.   The CISCO UCCX, for example, has a step by step debugger built right into the script editor, which is really helpful for those of us who have to design, implement and test these scripts.   It turns out that ShoreTel has one as well, you just have to know where to find it.   Again it is not documented and is well known only to those that know it well.

In this video clip we take a look at the tool and show an example of how you might use it to unravel a particular SQL data dip problem.    We have found a number of these tools and we are always looking for documentation and road maps produced by those who have gone this way before!   Next blog we will take a look at a TAPI debugger that is also very useful when troubleshooting ShoreTel phone system Communicator issues.

At any rate, the ShoreTel ECC has great potential and is a wonderful solution when applied in the proper environment.   You can create some very sophisticated routing applications based on a variety of CRM integration, custom software solutions and IVR scripts.    Despite all our grumbling and complaining,  we have not found anything we cant make work on a ShoreTel ECC!

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