ShoreTel Route Point Configuration

Thecr ShoreTel IPBX “Route Points” are powerful configuration tools, 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! More on this later, film at 11.

New family of ShoreTel SG voice enabled switches!

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.  (Click here if Video does not load).

ShoreTel Linux Based Voice Switches

Deploying the ShoreTel Personal Call Manager through AD Group Policy!

Installing a ShoreTel IPBX solution is a process not an event. I have previously published a book entitled “VoIP System Planning Guide” that can be download from the DrVoIP site. This guide covers the basics for planning and managing a VoIP deployment in general and a ShoreTel solution in particular. The “devil is in the details” however and though the process can be understood, the individual tasks required to complete the process generally prove there is no substitute for hands on experience!

Every installation technician comes to that fork in the road that deals with the deployment of the ShoreTel Personal Call Manager software. Deploying the actual telephone instruments is a pure act of labor, but the Personal Call Manager is an act of commitment! Each desktop in the installation will need to be touched by someone, and I do not consider an installation complete until the Call Managers are deployed and operational. There is a component of this effort that involves interVLAN routing, (e.g. getting from the desktop data network to the phone server), but I am now focused exclusively on the actual installation of the PCM software.

There are three strategies that are generally employed to accomplish this. The first strategy is obviously to visit each desktop with a DVD or Thumb drive and load the software! For the installer this is very labor intensive and requires that the install have administrative desktop privileges or maybe even domain privileges. The second option, is to push the software out to the desktops through and email link set from the ShoreTel Director portal to each ShoreTel user. This is a bit less labor intensive, but it still requires the desktop users to have administrative installation rights to their own desktop computers. Most large IT environments do not grant this privilege to plain vanilla users!

The third option, however, has the most promise as being both labor economical while maintaining network security. We can create and Active Directory Group Policy to push the PCM out to the user and have it installed without user involvement. To do this you will need to create a few objects, modify the organization unit containing the computers and users that will be effected by the new group policy. (Refer to Microsoft Knowledge base article 816102). First you create a Distribution point; the create a Group Policy Object, assign a package and then publish your installation package. This strategy is the preferred implementation practice for deployments of any scale and installation technicians should become familiar with the basics of implementing this solution. We will publish a video on both the blog and the DrVoIP site that will demonstrate this solution.

VoIP and SRST/AES Encryption!

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!

How to backup your ShoreTel IPBX!

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

How to Backup a ShoreTel IPBX Version 7+

What is a ShoreTel DVM and why do I need one?

What exactly is the value of a Distributed Voice Mail Server (e.g. DVM)?   What are the pro’s and con’s of installing one?  Does it have any impact on resiliency (not redundancy) as it relates to business continuity in the event of server failures?  ShoreTel has a distributed architecture but like all other VoIP solutions there is only one “read/write” database and that is a component of the ShoreTel architecture aptly named the HQ server.   IF this server goes down and the R/W database is unavailable configuration changes can not be made throughout the “single image” installation.

Installing a DVM at the same level, or in the same site as the HQ server, provides a high degree of resiliency at comparatively low cost.     At the HQ site, put all your HQ users on a DVM.   If the DVM goes down, the HQ will pick up the heavy lifting for the Users on the DVM.  If the HQ goes down, the DVM users will still have VM and AA services.  As of today, there are three services, however,  that are NOT distributed in the ShoreTel architecture. These services are known as Workgroups, Route Points; and Account codes.   If you lose the HQ server, you will lose these services for all sites, even if they have a DVM installed at that site!

As it relates to low cost business continuity options, we like to install a DVM at the HQ site, but we want all switches at all sites to be managed by the HQ server.   This usually provokes a heady discussion, but here is our reasoning.   The real value of a DVM is to keep VM and AA media streams off the very expensive WAN connections. Remember that a DVM can fail up, which means the HQ server can take over Voice Mail and AA processing for the users at a site that has a failed DVM.   It makes sense to put the users at a remote site on the DVM at that site, but does it really make sense to have the switches at that site managed by the DVM at that site?

We think not.   Lets separate the issue of Users and Voice Mail from issues like TAPI, Workgroups and Personal Call Managers.   We need to remember that if a server goes down, the switches managed by that server will lose all the TAPI information for the phones that it controls.  This means you will have no functioning Workgroup Agents and not ability to monitor those Agents. Additionally, the Personal Call Managers will not work for any extensions on switches managed by the down server.

Given that Workgroups is not a distributed service, if the HQ server goes down, you will not have Workgroups anyway.   If the DVM at a remote site goes down, the HQ server will proxy for that sites Voice Mail and Automated Attendants.  Given that the HQ server was managing the switches at that remote site, you will not lose any of the PCM functionality highlighted above.  It occurs to us that this is a better place to be.   Let the HQ manage all switches and use the DVM’s for Voice Mail services for the users at remote sites!  Use a DVM at HQ for additional resiliency.

Voip Network Monitoring

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

networkmonitor