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.

Trouble shoot “one way media” with the ShoreTel “phonectl” command! is a post from: VOIP Tech Blog

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.

ShoreTel Route Point Configuration is a post from: VOIP Tech Blog

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

New family of ShoreTel SG voice enabled switches! is a post from: VOIP Tech Blog

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.

Deploying the ShoreTel Personal Call Manager through AD Group Policy! is a post from: VOIP Tech Blog

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!

VoIP and SRST/AES Encryption! is a post from: VOIP Tech Blog

How to Backup a ShoreTel IPBX Version 7+

How to backup your ShoreTel IPBX! is a post from: VOIP Tech Blog

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.

What is a ShoreTel DVM and why do I need one? is a post from: VOIP Tech Blog

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

Voip Network Monitoring is a post from: VOIP Tech Blog