VOIP Tech Blog

One of the most common make/break/fix support tickets that come into the TAC center, have to do with “one way media”. In this scenario, a ShoreTel VoIP phone user calls another phone user, or places an outside phone call and the called party can hear the user, but the user can not hear the called party. We typically refer to this condition as “one way media”. We have look at hundreds of these situations, and though some were more difficult to resolve than others, they are generally attributable to a configuration error that defines the default gateway or a missing route.

Conceptually, your IP phone sits in a specific network. For example, your IP phone might have an IP address of 192.168.150.55 which is in the 192.168.150.0 network. When that device setups up a phone conversation to another phone, media(read voice) flows between the two devices. It is important to know that the “call manager” that provides the MGCP call setup and tear down information is the ShoreTel switch that the calling phone registered with, but the actual media stream, is between the two end points only. You can use the phonectl command to see which Shoregear gateway is managing the phone.

Generally, we experience the condition known as “one way media” when a phone in one subnet calls a phone in another subnet. In a multi-site deployment your phone may be in the 192.168.150.0 network, but the phone you are calling might be in the 172.16.10.0 network. The ability of these two end devices to set up a media stream requires that there be some routing device in the network. This routing device may be an actual router, or it might be an Ethernet switch that has “L3” (read routing ) capability.

When a device on the 192.168.150.0 network wants to exchange packets with a device on another network, it sends those packets to the “default gateway”. The default gateway is an interface on a device that knows how to “route” to the other networks. Each device knows about the devices on the network it is resident in. It also knows that if it needs to communicate with a device in another network, it needs to send that request to the default gateway. The default gateway, will then forward it on to the target device, or to its own default gateway, until it reaches a device that knows the target device.

There are a few questions you need to ask when troubleshooting one way media:

(a) Can I make a call between phones in the same network?

(b) Can I ping the ShoreTel HQ server:

(c) Can I ping the ip address of the device (phone or gateway) that reports the one way media;

There are a couple of ShoreTel related exe files that are useful in trouble shooting one way media. You are going to want to see the network from inside the network device, regardless if it is a switch or a phone. ShoreTel has a security shell that runs on phones and switches. You will need to disable this shell, to enable the ability to telnet into the switch or phone. First, you will need to enable telenet with the ShoreTel ipbxctl command. You will also use this command to telenet into a phone (see previous blog “how to telenet into a ShoreTel phone). You will then telenet into the phone and test for network connectivity by use of the PING utility.

Invariably one way media can be traced to a network configuration error. Either a device somewhere in the network has the wrong default gateway; or the default gateway does have route to the destination network. As an aside, there was a time in which the standard ShoreTel media stream, always used transport level port 5004. A one way media condition, generally across a WAN, might be the result of having port 5004 blocked in one direction on a firewall. From a QOS perspective, advantage to ShoreTel as we could not only prioritize Voice over Data at the IP level but also at the TCP or transport layer. With the move to SIP, the RPT media stream is moving on ports all over the map so this is no longer high on the check list.

DrVoIP ShoreTel Configuration, Shoretel Support and Service, VoIP Network Configurations ShoreTel phonectl

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.

DrVoIP ShoreTel Configuration, Shoretel Support and Service, VoIP Network Configurations, VoIP Tech Tip route points, ShoreTel Route Point

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

DrVoIP ShoreTel Configuration, Shoretel Support and Service, VoIP Network Configurations shoretel sg

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.

DrVoIP ShoreTel Configuration, Shoretel Training, VoIP Network Configurations, Voip Service & Solutions Shoretel IPBX, ShoreTel Personal Call Manager

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!

DrVoIP Cisco Voip, ShoreTel Configuration, Shoretel Support and Service, VoIP Network Configurations SRST AES encryption, voip, voip Encryption, voip systems

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+

DrVoIP ShoreTel Configuration, Shoretel Support and Service, VoIP Network Configurations shoretel, ShoreTel maintenance, shoretel systems, shoretel version 7, softswitch

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. 

DrVoIP ShoreTel Configuration, Shoretel Support and Service, VoIP Network Configurations Distributed Voice Mail Server, DVM, dvm users, ShoreTel architecture