Recently in Shoretel Category

 The ShoreTel IPBX "Route Points" are powerful configuration tool, generally used to enable third party applications. Using route points, an external application can gain complete call control. For example, when you configure a ShoreTel Enterprise Contact Center, you will use route points to control call flow, media and routing options. The interaction with the route point is generally through TAPI and TAPI wave, but route points can be used to create other options for call control including call deflection and the creation of voice message repositories. Playing with route points is an interesting experience as they seem to work differently depending on which version of ShoreTel you are running. In all versions, however you can create a route point and associate it with a voice mail box, or use it to deflect a call. Historically, we have used route points, along with schedules, to redirect call center traffic between different call centers based on the time of day or day of week. It is quite possible, however to set up a route point for no other purpose than to create a fully functional voice mailbox. Given that the route point does not require the definition of a user, no extension or mailbox license is required to achieve this result. Basically, you create an route point much the way you would create a Hunt Group, Automated Attendant or Workgroup. You define the route point with an extension that can be dialed, and you setup your Ring No Answer and Busy Destinations to be the voice mail port. We have come to realize that you have to use the Record function on the Route Point configuration page to set the recorded name and greeting. Thought we could enter the same VM box through an IP phone and were greeted with the normal new voice mail box setup routine, when we called the box we did not hear the name or greeting. Using the record option on the configuration page, however, enabled this functionality. After recording the greeting and name in the way, we experienced the expected behavior when we called the extension and were transferred to VM. Route points can also be used to deflect an incoming telephone call to an external telephone number. This is equivalent to setting your call handling mode to always call forward to an external number. We never encourage users to configure this option in their call manager, as it robs the host company of follow on call control, allowing messages to be taken by a cell phone for example. The fact remains, however, that you can setup a route point, with a DNIS or DID number to always send the call to a remote phone in the pubic switched telephone network. Route points that forward to traditional TDM connections will actually show up in the ShoreTel CDR when you run a User Detail or Summary Report. This is not the case if you try to run these reports against a route point that is actually used as designed and terminates in a third party call control application via TAPI. This is just one of the mysteries of route points. At the end of the day you could setup a ShoreTel server with no users or extensions, using route points to enable both voice mail and remote call forwarding. Route points are just way kool and worthy play things! Click this link for Video demonstration of this ShoreTel Option. Drvoip@drvoip.com

In this economy there are a growing number of mergers and acquisitions, or "marriage by shot gun". When companies combine they have the challenge of integrating their data and telecommunications systems. For example, we have witnessed an increased demand in companies seeking technical assistance in merging ShoreTel systems. There are two basic options for doing this and the choice often depends on resource requirements and "dial plan" conflicts. To illustrate these options let's assume Company A merges with Company B. Both companies desire the integration of their telephone systems if for no other reason than to enable extension to extension dialing.

The first option is the traditional single image option. Assume that Company A will become theHQ Server and the other Company B will become the DVM server. To accomplish this, the database of Company B will be manually imported to the HQ server and a new site is created.( Clearly, the WAN solution is in place and connectivity between the two companies exists).When you complete the database additions to the HQ server, adding all the new users, switches, workgroups, hunt groups and site details you are ready to convert the Company B HQ server to a DVM. You are going to have to reconfigure the site switches to point to the new Company A HQ server, but the process is manageable and you should achieve the desired result with limited down time.

The second option is less obvious and many ShoreTel field installation technicians will not be familiar with the option. Out of the box, ShoreTel supports site based Prefix Dialing. In our example, we would leave both Company A and Company B with a HQ server. They would appear to be two separate systems. The use of the Prefix dialing, however, makes it possible to enable extension to extension dialing between the systems. Through the ShorewareDirector web portal, you would select the Dialing Plan from System Parameters. The dialing plan would enable you to select a digit for extension dialing, with from 1-7 prefix digits.In our small example, we might make use of Digit 7 with a prefix of 2 digit, allowing us to create 99 sites. When you exercise this option, you will see a new field appear in the SITES definition in the ShorewareDirector portal. Entitled "Extension Prefix" the field enables you to assign a two digit SITE ID to each site you create. As you assign users to SITES, their extension numbers become the SITE ID + Extension number. Given that we have a WAN solution in place, we can then establish SIP Tie Trunks between Company A and Company B. The Trunk Group that defines the TIE LINE would have an OPX (off premise extension ) list that defines the extension range that "lives" at the other end of the TIE line. Company A might have a prefix of 77 and Company B might have a prefix of 78. Users in each system, even though they were previously defined with a three digit "dial plan" would now show 77-123 or 78-123 when you reviewed their individual USER configuration in ShorewareDirector. Assume further, that both companies had similar "dial plans" meaning that they had the same extensions assigned in both companies! The extension prefix option working as a site ID, enables both companies to keep their extension numbers.

(See blog.drvoip.com for graphic illustration) 

Arguments can be for, or against either option. A single image solution has real advantages in that there is a single point of administration, and a single VM system. Others would argue that redundancy and increased resources favor the second option. Remember that currently, ShoreTel "Workgroups" are not a distributed service. The second option enables some workgroup survivability given an HQ server failure. Prefix dialing has a place in the integration of independent systems and can work to reduce HQ server work load while increasing resources and mitigating dial plan conflicts.

 Every call center has peaks and valleys.  Normal businesses operate with very predictable calling patterns.  Traffic over the normal business day, starts out slow and peaks between 10AM  and 2 PM in the afternoon, then trickles down.  The old Bell Curve distribution pattern!   Call centers on the other hand, have very different call characteristics depending on the nature of the business.  One characteristic that we can be confident in, is the fact that there are more callers than "agents" to service the calls.  Thus the need for some kind of qeueing capability.

"We are sorry, but all available agents are working with other clients.  Please hold the line and the next available agent will be right with you.     Unfortunately,  callers might tire of the music on hold and predictable care messages, and ultimately give up and then hang up!   This is generally an "abandoned call" in most contact center environments and reports.    The ShoreTel Contact Center has a facility for capturing this information and doing something producitive with it.

Back to the concept of  "Peaks and Valleys".  What if we could take the "abandoned calls", capture the caller id and feed them to our agents during valleys in the calling periods?  After all the staff is sitting there, logged in and idle!  Lets just put them to work.   In a ShoreTel system this is very easy to setup and is a powerful productivity tool.  First, the system "reserves and agent".   The agent gets a little pop up window that informs them that they are being reserved for a call back.  They have to accept it, or they are put in "release" as if they turned down an incoming phone call (time for management tutoring).   When the agent accepts the reservation, the ShoreTel places the outbound phone call and then connects the call to the agent.   With the exception that they acknowledged the reservation request, the agent experiences the call as if it were any other in bound call to the contact center.

Optionally, you can play a file to the callED party before you send the call to the agent.  I have found however, that it is better to send the call to the agent immediately after it is dialed.  This is because the agent is better able to deal with "positive answer supervision" using the human ear, then the machine is able to tell the difference between a fax machine, answering machine or someother non-human answer.

Making use of the abandoned call feature is something that every Contact Center can do to increase agent productivity and customer satisfaction.   You can even setup a group that specializes in abandonded call backs, and route all calls to that "win back" group.    The following video describes how to set this up in your ShoreTel Contact Center (or you can just call us, and we can do it for you)!  

 Fax Machines on ShoreTel?   It is not uncommon for system administrators to create a user named FAX SEVER, then define it as EXTENSION ONLY.    Though I personally have been trying to eliminate all the forest eating fax machines and printers on the planet, it would appear that Fax machines are going to be with us for quite some time.   Even with a fax server, people want to stick a piece of paper into the machine and watch it "go through" after dialing the distant end.  This is an example of  "Experiential compatibility" as the marketing folks like to say.   We are more comfortable with a technology that is compatible with our experience.

Microsoft Office Communications is a powerful collaboration tool.  The MOCS provides web conferencing, IM, audio conferencing, desktop sharing and also provided  SIP.   For purposes of this brief discussion, we will stay focused on the Internet Messaging component of MOCS.     With the Release of ShoreTel 8+, the Professional Call Manager  provides both desktop to desktop video conferencing and Internet Messaging.   The Internet Messaging component makes use of a Microsoft OCS server and the ShoreTel solution integrates the solution as an application server defined within the ShorewareDirector portal.

 Internet Messaging, or IM as it is popularly referred to, seems to fall into two corporate philosophy camps:  companies who absolutely abhorrer its use; and companies who find it to be an essential business tool.  Those companies who do not allow IM of any kind typically have very tightly controlled employee desktops, enable website filtering and block IM ports for Yahoo, AOL, Google and others.    Sometimes the excuse is HIPA/Sarbanes Oxley compliance or a general concern that employees might communicate private company information out this internet portal.    Companies that find IM to be essential can be broken down into two additional categories: those that allow IM clients on an ad hoc basis and those who want total control of the IM client.

Microsoft OCS provides a solution for that last group of customers; those that need IM but want to control and monitor its utilization.   MOCS enables you to "record" all IM conversations to an achieve server to meet those HIPA and Sarbanes Oxley compliance requirements and to assure the content of IM does not violate Corporate use policy.   MOCS also enables you to set up "federations" so that inside IM participants across the Company can communicate with Yahoo, AOL or Other corporate MOCS users outside the domain.   All in all, MOCS is the great unsung hero of the Microsoft Servers!

The integration of ShoreTel Professional Call Manager and the MOCS is not that complex, but falls under that summary statement "well know, to those who know it well".    Microsoft clearly has a VOIP strategy in which the MOCS plays a key role.   Working with a ShoreTel IPBX and a Professional call manager, it becomes a viable solution for adding IM to and existing ShoreTel voip installation.  The video is just a quick overview of how you actually deploy the integration.  

We have been actively working with VoIP since 1999!   Since 2001 we have installed well over 10,000 ShoreTel desktops and one characteristic of these VoIP environments has surfaced into high relief on the radar screen here in technical support:  A VoIP solution is only as good as the computer Network it runs on!    Network Monitoring - a Necessary Evil?  When someone mentions network monitoring, most network administrators immediately start thinking: overpriced, large server requirements, difficult to install, time-consuming to configure.  If those hurdles are overcome, then there's a potential rainbow at the end of the road: Immediate notification of problems, faster problem resolution, less downtime of services.  That equates to happier & more productive users, and a more profitable organization. What's interesting to realize is that the vast majority of companies all want to know the same things with their network:

• When do problems happen?
• Where are the problems?
• Why do these problems exist?

We have decided to create a product that eliminates all of the hurdles and answer these same questions no matter how large or complex a network was deployed.

 We can now:

• Deploy and auto-discovers your entire network in just a few minutes
• Continuously monitors the health of every device and interface on your network

 This allows for some proactive analysis that includes:

• Quickly learn which interfaces in your entire network are discarding packets
• Perform a call path mapping of the health of every interface used in a VoIP call
• Run a call simulation from any computer to any IP endpoint (including router interfaces)
• Know what your current Internet utilization is - live (updated every 2.5 seconds)
• Learn the switch and port where your VoIP phones are connected

Contact us today and we will send you a FREE completely operating network monitoring system for your evaluation.  Send a return email that lists:

• Company Name
• User Name
• User email address
• User phone number

And we will email you the download link and evaluation license code! Our only requirement is that you be a ShoreTel  system user.!  DrVoIP@DrVoIP.com

Prior to version 7 of  ShoreTel, backing up your ShoreTel system was very straight forward. There was a single folder in the root directory named d:\ Shoreline data. This folder contained all the information that was required to completely restore your ShoreTel system from a bare metal server in the event of a major disaster. The folder contained the configuration database, which at the time was kept in Microsoft Access. It also contained all of your recorded prompts for Automated Attendant, your voice mail messages, all of your Call Detail Records and softswitch related information. You could easily identify this one folder and make it a part of your normal system backup process for your company. With the introduction of Version 7 of ShoreTel the company began to migrate away from the Microsoft Access database and move toward the MySQL database. First they moved the Call Detail Records and with Version 8, the entire configuration database had migrated to MySQL. For this reason the database backup process for a ShoreTel system has changed. The process must now include the backup of two MySQL databases and the aforementioned Shoreline data folder. ShoreTel does provide a few BAT file examples of how you might do this, but if you want to automate the process complete with a schedule you will want to consider using some other tools. We recommend the use of SQLyog and include a copy on every server that we support or install (just another reason to have DrVoIP do your ShoreTel maintenance). Send an email request to drvoip@drvoip.com and we will send you a tech note that details this process or you can watch this silent video .

 As noted in a previous post, there are reasons that you might want to consider using the standard Agent tool bar.  The Standard Agent tool bar enables the manipulation of an call center contacts (voice, email and chat)  with an unobtrusive GUI.  The toolbar can be standardized for each agent or a supervisor can allow agents to create there own tool bars.  There is a setup icon that enables the ability to add or remove icons associated with different contact center functions.  Again, the system administrator can "lock" this function and push out a standard Agent tool bar to assure system uniformity.   In a "shift" based contact center in which different people sit at the same desk and extension at different times (e.g. Day, Night, Weekend) you can create an Agent tool bar icon that will prompt the Agent to enter their Agent ID and Extension number.  In this way, the ShoreTel PBX can be setup with non-specific users, as the ShoreTel Contact Center can track usage by Agent ID.

Signing into the Agent tool bar prompts you to enter three items of information: Agent ID, Agent Extension and Email Address.  The Agent Email address is only used when your ShoreTel Enteprise Contact Center is setup to route incoming email messages to the next available Agent, in a manner similar voice calls.  Once logged in, there is an icon for Agent tool bar setup.   There are four basic areas of tool bar setup:  Telephony, ACD, Window and Other.  The Telephony setup enables you to add icons for common phone features like transfer, hang-up, conference and Divert incoming call!   The ACD setup enables wrap up, release and other common functions including the ability to request Supervisor Intervention.   There is a Call Window, Queue monitor, Telephone manager and Desktop Wall Board in the Window setup section and currently the "other"  option enable you to create an icon for launching an external application.  There are also tabs for setting Preferences, Contact Information, Ring and Queue Alerts.

 At the bottom of the tool bar there is a "status" line that displays information.   Idle, Ringing, Connected and Held are common staus indicators, but you can also "write" to the status line.   This is another advantage of this tool bar over the integrated tool bar.  Similarly you can change the information that is displayed on the Queue Monitor or Agent Wall Board which are pushed out or available to the Agents.  Some of this information is contained in the system defined Call Profiles, while other information is contained in the user defined Call Profiles.  (Call profiles are described in detail on the www.drvoip.com instant online video training library).  These options work together to create a very powerful desktop call management center, in a compact GUI.   The silent video demonstrates the various configuration options and shows the easy with a customized tool bar can be created.  The actual tool bar in this example, is a Supervisor tool bar in ECC 5.0 but it looks the same as an Agent tool bar! 

Encryption of VoIP traffic was, for some of us a humorous concept. I remembered as a young development professional how much fun it was to use a packet sniffer to capture the bosses packets and reassemble his email over the LAN.  Years before that when I worked at the phone company as a central office test engineer, it was not uncommon to find an interesting phone call and plug it into the over head paging system to provide entertainment for the late night test  crew. There are times  I still think the concept of encryption on VoIP is humorous, but it is becoming less funny all the time as we move toward end to end VoIP with no TDM at all in a world populated by terrorists and other evil doers.  In any VoIP environment today, you can at some point use the usual tapping tools to capture a phone call as it hits the  TDM gateway and is converted from VoIP to traditional analog or digital signals.  From an induction coil to a line mans butt set, you can still intercept a VoIP call as it crosses the TDM boundary.

Now that VoIP is being used end to end, we do need to have a mechanism for encrypting at least the media stream. Today we generally do that with SRTP and IETF standard in combination with AES. AES or the Advanced Encryption Standard was adopted by the US Government and comprises three block ciphers: AES 128, AES 192 and AES256. Each AES cipher has a 128 bit block size with key sizes of 128, 192,and 256 respectively. This standard has generally replaced the former Data Encryption Standard or DES. It is important to understand the difference between encryption and authentication. Determining that a signal is "authentic" and originated from a source we believe to be authentic, and encrypting the contents of that communication are two very different issues. Media authentication and encryption ensures that the media streams between authenticated devices (i.e. we have validated the devices and identifies at each end) are secure and that only the intended device receives and reads the data. We need to encrypt both the media (i.e. the voice) and the signaling information (i.e. the DTMF). In most VoIP systems today, SRTO or secure RTO is implemented to assure media encryption. Understand that this encryption is not passed through to the TDM network, so once the media stream leaves the VoIP environment it is subject to eavesdropping.

Clearly as we are now able to employ VoIP end to end, SRST/AES encryption has very powerful ramifications for both the good guys and the bad guys!

ShoreTel has a family of new media gateways.  The more interesting switches are referred to as SGV switches.  There is an SG50V and an SG90V that differ only in the number of FXO and FXS ports that they support.  What makes these switches (i.e. media gateways) so interesting is that they have a LINUX kernel built in to support a Compact Flash Card which enables localized Automated Attendant and Voice Mail.   In the world of ShoreTel's "single image solution" we have the concept of a DVM (e.g. Distributed Voice Mail sever.     The DVM are typically deployed at remote sites and, as explained in previous  blog, provide for a level of resiliency (not redundancy) in your multi-site solution.   More importantly, as the DVM enables Voice Mail and Automated Attendant to be localized at a remote site, it keeps these bandwidth intensive functions off your very expensive WAN. 

For example, if I have a New York HQ site with users, media gateways and workgroup services; I might have a North Carolina remote site with a DVM, media gateways and users.   Workgroups are currently NOT a distributed service, so any workgroup functions will require the HQ server.   However, in North Carolina I can assign the users at that site to Voice Mail boxes on the DVM at that site.   Callers to telephone lines that terminate on media gateways at that remote site will be answered with an Automated Attendant that lives on that remote DVM, eliminating the need to stream that media across the very expensive WAN.  (Note: historically the media stream was G711 as it originated from the server regardless of the Inter-site codec.  Recent release of ShoreTel enable a HQ media gateway to proxy the media stream enabling the use of the lower bandwidth Inter-site code).    Should the DVM at the remote site fail, the HQ server would take over for the remote site.  In this way VM and AA are still provide to the remote users.

The new SG50V and SG90V are typically used as replacements for or instead of a DVM at a remote site.   The question arises as to what would happen if you added an SG50V or SG90V to a remote site under the control of a DVM?  One would argue that it would make no sense to install  these media gateway in that scenario.    In the ShoreTel architecture it is important to note that DVM's fail upward.  For this reason we might install the SGV media gateway as a new site under the remote site.  So in this example we might install a new site under North Carolina and put the SGV media gateway in that new site.  Then we might move all the users at the North Carolina site to the new SGV media gateway for voice mail and automated attendant.  In this way, the SVG should it fail, would have its services picked up by the North Carolina DVM; which in turn should it fail, would have all services picked up by the HQ server. 

The new SGV switches are very interesting building blocks for the ShoreTel architecture and should be studied in some detail.  They also might indicate a move by ShoreTel away from both Microsoft and VxWorks.   This is only conjecture on my part and not based on any fact other than that we which can all observe.  ShoreTel has dropped the Microsoft Access Database in favor of the MySQL database engine.  Clearly this could be just a cost cutting move.  However, the SGV switches, do not have VxWorks, they have a Linux kernel.    Taken together these may in fact be an indication of a product road map that is moving steadily toward a total Linux based solution.

Find this and other videos in our video library at www.drvoip.com