Author: DrVoIP

Peter S. Buswell (aka DrVoIP) is a rare blend of C-level executive leadership and deep technical expertise in telecommunications and cloud infrastructure. With a career that began at AT&T in 1970, he has founded and led multiple industry-defining companies, including Dextr.Cloud—acquired by AWS Global Partner CloudHesive. Peter has held senior roles at firms like Exxon Enterprises, Intervoice/Brite, and Franklin Telecommunications, and has consistently driven innovation from traditional PBX to Amazon Connect cloud deployments. A hands-on architect with certifications from Cisco (CCNP/CCDP, UCCX/UCCE) and AWS (Solutions Architect, Developer, SysOps), he combines strategic vision with engineering precision. Known as DrVoIP, he continues to bridge the gap between enterprise goals and technical execution in today’s evolving cloud communications landscape.

Why move the Auto Attendant into the Contact Center?

Posted on January 9, 2010 by DrVoIP

Many Call Center applications have an Automated Attendant front end call tree. Typically, you might have an Automated Attendant that plays the familiar On-Hours recoding: “Thank you for calling our company, press 1 for technical support and 2 for sales support”. The question asked in today’s blog is: should the Automated Attendant be located in the PBX or in the Call Center? There are very interesting ramifications for each of these options.

Generally, with out thinking this question through, the easy answer is to have the PBX do the front end Automated Attendant. In the ShoreTel world, the On-Hours/Off-Hours scheduling of the changes to the call tree and messages played is so “brilliantly simple” that everyone will select this implementation strategy. In our simple example above, selecting either option will direct the caller via a route-point/IRN marriage into the Contact Center to be processed by the appropriate Service, Group and Agent.

If you implement that Automated Attendant in the PBX, however simple it is, you potentially rob management of very urgent call detail information. Typically, the Off-Hours location is a general delivery mailbox in the PBX anyway, so why not just keep it all in the PBX? If the Automated Attendant shuttles calls to the Off-Hour location, that call may never become known to the Contact Center and therefore would not be captured in the Contact Center Historical Reports. Call Center Management might be very interested in knowing how many calls came into the Center before or after On-Hours! To obtain the information the Call Center, not the PBX needs to host the Automated Attendant!

What is the result of implementing the Automated Attendant in the Call Center? If you look at the above Automated Attendant script, you can see immediately that we need to add the famous “If you know the extension number of the person you want to speak with, dial it at any time during this recording”. Given that you have already concluded that this is an option you want to offer clients, something a Call Center manager might not recommend, how do you implement this feature using the ShoreTel Contact Center?

There are several ways to do this on the ShoreTel ECC, but all options require the creation of a “Call Profile” value. We have put together a quick video tutorial on how to implement a multi-digit transfer in the ShoreTel Contact Center using the Graphical Scripting Tools. Minimally, after you create the Call Profile value you will need to have a “Get Digits” and the “Transfer” Icon. In our example, we have created a Call Profile value named “ExtensionNumber”. This value anticipates a three digit integer and does not require a termination character. The GetDigits Icon is normally associated with a WAV file that prompts the caller for digits. Once the digits are collected the are deposited into the Call Profile place holder named “ExtensionNumber”. This value is then past to the Transfer Icon and the value is dialed by this function. Enjoy!

Mobile Call Manager for the iPhone?

Posted on December 29, 2009 by DrVoIP

One of the benefits of a successful blog, is the talented people you meet and the ideas that you exchange with other industry professionals. Through an earlier blog on the subject of connecting an Apple Iphone to a ShoreTel System as a SiP extension, I met such a creative talent: Matt Vlasach of Pacificswell! Matt was both an excited ShoreTel user and a Iphone aficionado. Thought Matt was happy to play with SIP his real interest was in creating a ShoreTel App for the Iphone!

As a result of Matts talented development team at Pacificswell, I have had the pleasure of playing with a beta version of StreamLine, a mobile call manager for the Iphone! If you have always wished that ShoreTel could work on your Iphone, your wish has been granted! Pacificswell’s first release of the App is a useful, easy to master, technically brilliant mobile call manager! Using Streamline you can remotely connect to your ShoreTel server and setup your call handling modes and activate your Office Anywhere feature. The App is intuitive and graphically obvious!

Even using the Apple developers platform to obtain the beta version ( an Apple strategy for enabling developers to offer the App before it appears in the App store), the download and install was remarkably simple. It downloads and installs using the already familiar App Store process! Configuration was a breeze and I had the App up and running in under five minutes.

Clearly there are some server side issues that need to be addressed and license compliance issues for the ShoreTel Mobile Call Manager, but technically, the App is brillant. More importantly it just works! I was able to select either my Office desk phone or my Iphone as the primary answer point. Each of the Call Handling modes can be accessed in a visual graphic that is experentially compatible with the ShoreTel user interface for setting up Call Handling Options.

Product Development is a process, not an event! Matt assures me that he will continue the development and enhancement of this App adding more features in future releases. The product can be explored in detail on his site at Pacificswell and I have included some screen shots below!

Keep the cards and letter coming! The App will be available at the Apple App Store on January 4th!

Select your Desktop or Iphone as prmary answering point!

ShoreTel Enterprise Contact Center Call Routing based on Schedules!

Posted on December 5, 2009 by DrVoIP

If you have been following our tech tips, you know that route points in the ShoreTel IPBX have a matching IRN in the Contact Center. If you want to route a call to a different destination based on the date and time that a call hits the Contact Center, how and where would you apply the schedule? Technicians familiar with the ease of creating schedules in the ShoreTel IPBX, might immediately apply a schedule to a route point. After all, each call to the Contact Center hits a route point first, why not apply the OnHours/OffHours call handling directly to the route point?

At the end of the day, Contact Centers are designed to provide management, detailed information to facilitate staffing, allocate resources, decrease call holding time and increase customer satisfaction. Candidly, it is all about REPORTS! My personal prejudice is that contact centers should be designed by starting with Reports! What is it that Management wants to see? If we want to know how many callers are hitting the Contact Center during Off-Hours, for example, we can not apply the schedules to the Route Points. If the Schedule applied to the Route Point deflects the caller to a Voice Mail box, that call will not appear in the total Calls presented to the Contact Center.

If you want the call to be counted, it must actually enter the Contact Center! For this reason, most Contact Center deployments are deployed with the Automated Attendant functionality being defined within the Contact Center. In this way we can accumulate accounting information on all calls that hit the Contact Center, regardless of how they are ultimately routed. The ShoreTel Enterprise Contact Center has a very powerful configuration capability as it relates to defining Schedules. Schedules are defined as “types of days” and “shifts”. At first this concept is a bit difficult to digest, but once you play with it you will realize just how powerful and impact this configuration strategy can have on your overall Contact Center call flow.

The Working Times facility enables you to define a type of day and then associate shifts to that day type. The normal ShoreTel Schedule works on a binary On-Hours Off-Hours call handling model. What happens if you want to build a call flow that needs to have calls routed differently between specific hours of the day. For example, between 12AM and 8PM, we want incoming calls to be routed to the Guard Station. Between 8AM and 12 Noon we want a live answer point at the Reception Desk. Between Noon and 1PM calls need to be routed to an outside answering service; and between 1PM and 5 PM they need to be routed back to the Reception desk. Now any technician that has been working with the ShoreTel IPBX for any period of time has developed several strategies for handling this often required call flow. The strategy usually involves cascading Hunt Groups in combination with Workgroups to achieved the desired result.

The Working Times facility within the Contact Center would handle this complexity with ease. You would define a Day Type (i.e. WeekDay) and the define the various Shifts that comprise that day. In the example above, the ticking of the clock would transition through the various “shifts” resulting in a different destination based on the time of day. This is advantageous in a call center environment and significantly less demanding to administer than the cascading Hunt group strategy. Contact Center call flow is often managed on a time of day, day of week and holiday basis at a level of sophistication that goes way beyond the On-Hours Off-Hours approach to call handling. The ShoreTel Enterprise Contact Center Working Times facility is a power strategy for achieving maximum call routing control.

VoIP QOS Network Monitoring and Pathview Cloud!

Posted on December 3, 2009 by DrVoIP

Trouble Shooting VoIP issues in a multi-site deployment is a challenge to even the most talented network engineer. It is often difficult to determine what is a voice equipment issue and what is an issue aggravated by a network conditions. As network engineer troubleshooting an issue, having access to network monitoring tools is essential. Sometimes we have to use the basic ICMP tool sets and ping our way through a trace route, but network connectivity is only one element of QOS related areas in a VoIP deployment. (Actually, it would be great if clients invested in putting network monitoring tools in place, but they only seem to appreciate their networks when something goes wrong)!

What is that we need to monitor anyway? We split the monitoring world into two basic camps: Flow based accounting and Health checking software. Flow based monitoring enables us to check the source/destination IP address; source/destination port; IP protocol; TOS and Ingress interface. This is helpful when you are trying to figure out what applications are running on your network and who is streaming real time media. Clearly important stuff, but at the end of the day, when it comes to logging into someone’s network remotely and trying to figure out why some remote user has garbled phone calls, there is nothing like an in place Health check!

When we talk about the “health” of the network we are interested in knowing about Bandwidth capacity, Loss, Jitter, Mean Opinion Score (MOS), latency and tagging.These are the words that make a VoIP engineer smile!Would it not be wonderful to log into your clients network and have this kind of history available between key end points of a multi-site deployment?Rarely, do I ever publically endorse a product but the folks Apparent Networks have gone out of their way to make their product available, useable and free!You need to stop what you are doing and download Path View Cloud, a host based network monitoring solution from Apparent Networks.

Not only is this software as useful as a button hole, but you can download a fully functional 5 node solution for absolutely no money! In previous posts, I have discussed the fact that, despite best practice, clients continue to attempt VoIP phone deployment over DSL through VPN tunnels! Path View Cloud enables you to collect real-time network health information about key endpoints in your network. Typically, it is the remote user or the WAN points that you are going to want to study. Path View Cloud enables you to create monitoring solutions that regularly report on health checks and trigger alerts when “violations” have been detected. Yes, Virginia, there is a Santa Claus and you can see packets!

Clearly Apparent Networks believes that offering 5 free nodes will get you to order more!The offer is, however, compelling and I can tell all you cheap, penny-pinching, tight wads that will not invest in network monitoring software, that you will sleep better at night with this Path View Cloud solution in place.Network and VoIP engineers and technicians, you need this arrow in your quiver to make troubleshooting more visual!

ShoreTel Enterprise Contact Center “Change Call Profile” icon

Posted on November 28, 2009 by DrVoIP

How many people hit the Auto Attendant and then dialed one for Sales? One of the most requested reports from ShoreTel clients is the analysis of Automated Attendant key strokes. With in the ShoreTel iPBX there are probably several ways to implement this, but we prefer the use of “route points” (see past blog). “ Thank you for calling our company during our normal business hours. For Sales Press 1, for Service Press 2 or stay on the line and the next available member of our staff will be right with you”. Typical Automated Attendant? We set the time out value to go to a “hunt group” and each of the menu items to a route point. You can actually run a User Detail report against a route point, as long as that route point terminates on a Shoretel end point other than a TAPI end point. For this reason, you can then run the report and find out exactly how many callers dialed one for sales!

Recently, we had to create an Automated Attendant on an Enterprise Contact Center. At first this seemed almost boring, but then we ran into an issue. You can use the MENU icon to create your Automated Attendant script, with a TRANFER icon to each destination selected by the caller. You can use the SCRIP icon to send the caller on to a script to collect information like the callers account number for a SQL database look up; but how do you send a caller to “service”? Now that was a more interesting challenge and I have to thank Chad Burnett for pointing out the use of what has become my favorite new ShoreTel ECC scripting icon: “the Change Profile” action. This icon is a powerful call profile manipulator and enables the Enterprise Contact Center configuration to explode with call processing options.

Using the Change Call Profile icon you can select various Call Profiles for manipulation. Each system contains a number of mandatory system level call profiles like ANI and Caller ID. You as a system designer can also create Call Profiles to meet the needs of your exacting design requirements. For example, you might add the Call Profile “Account Code” that you might use in a script that prompts the caller to enter digits that you will use to look up a record in a SQL database.

The Change Call Profile icon also allows you to select a previously defined SERVICE. The following video clip reviews how the iPBX and the ShoreTel ECC interconnect. It demonstrates the use of the Change Call Profile icon, by demonstrating the creation of a simple automated attendant!

SIP firmware for ShoreTel handsets?

Posted on November 22, 2009 by DrVoIP

To the sales team, I sound like a broken record as I repeated the engineering driven mantra: “A VoIP solution is only as good as the network it is build on”. No matter how many times we tell clients that you can not obtain reliable, predictable toll quality voice communications over the public Internet, they insist on having us implement it. The old marketing adage “you do not give customers what they need, you give them what they want” clearly applies and despite our best arguments to do otherwise; we find ourselves implementing VoIP solutions using VPN over DSL or Cable. The good news is that when it works, it is often useable for inter-office communications. When it does not work, it sounds like the worst cell phone call and would not be something that you would use to support business communications with a client.

In the VoIP world in general and the ShoreTel world in particular, there is a measurable performance difference between an MPLS deployment and a VPN tunnel through the public internet. An appropriately designed MPLS circuit with carrier Service Level Agreements in place will out perform the best VPN tunnel through the public internet. Yet clients continue to believe they can put a VoIP handset at the bosses house and run it over a DSL based VPN back to the “puzzle palace” and that it will perform as well as the phone on his office desk. The reality of the deployment is that this implementation seldom meets customer expectations.

A ShoreTel deployment of a remote handset for a home based work force can be accomplished under two basic models. In the more desirable, albeit more costly model, we create a “site” which involves the placement of a ShoreTel media gateway (read SG switch) at the remote location. VoIP handsets interact with the SG media gateway or call manager at the remote location for all call setup, addressing, signaling and control. In the ShoreTel world the call setup between a VoIP handset and an SG media gateway will use the MGCP protocol. This protocol is a client/server or master/slave model and when compared with other protocols can generally be summarized as complex and “chatty”. ShoreTel implements SIP for SG-SG communication, but uses MGCP for SG witch to handset call control. Once a phone call is setup up, only the RTP media stream needs to traverse the VPN tunnel, however.

The other less expensive model s the placement of a remote VoIP handset only. In this model, the handset is part of the “headquarters” site. Unfortunately this is the deployment model we see the most when clients attempt to interconnect a single home worker with the corporate network with out the benefit of a carrier SLA. A DSL, hopefully with a static IP address, and a device that can support a “point-to-point” VPN tunnel are the “minimum daily adult” requirement for VoIP connectivity. In this model, the VoIP handset is communicating MGCP over the VPN tunnel with a call manager at the headquarters location. Every handset action, from off-hook to digit key depress, is communicated over the VPN tunnel back to a media gateway at the home office. Very “chatty”.

As engineers we can talk ourselves into a coma when discussing QOS options, DSCP markings, router queuing strategies and bandwidth reservation parameters. At the end of the day, however, the only QOS “opinion” that really matters is what the users thinks! Mean Opinion Score or MOS is the measure of what users rate the quality of a phone call. Here is what we have learned after supporting hundreds of remote users on none SLA based circuits, typically VPN over DSL and Cable. Rule one: use only symetrical circuits (same up and down load speeds). Rule two: Hard phones beat soft phones; and Rule three: SIP phones beat MGCP phones. It is that simple. If we put a SIP based phone at a remote location, they will out perform an MGCP based handsets on the same circuit as measured by user MOS! The SIP phone will perform with a higher level of reliability, be more resilient to latency and jitter, and will experience significantly less call disconnects than an MGCP based VoIP handset.

If you study the hosted VoIP service provider market, you will find that the predominant VoIP handset deployment strategy is SIP based. Why is that? We could go completely geek on you and illustrate the complexity of call setup comparing MGCP with SIP setup messages, but why bother. MOS rocks. In this environment SIP deployments will yield higher customer satisfaction scores than MGCP deployments. We are sincerely hoping and praying that ShoreTel has a “SIP firmware load” on the product road map to support their family of outstanding desktop handsets as they do not have a SIP handset solution. Currently, when we have to support remote workers who insist on running VPN tunnels over DSL and Cable, we deploy Polycom and Aastra handsets to achieve maximum customer satisfaction in the wild west of internet telephony and home based workers!

Fun with ShoreTel Voice Mail

Posted on November 21, 2009 by DrVoIP

Stuck on how to get a WAV file of a professionally recorded voice mail greeting into the right ShoreTel Voice Mail box? After all there is no import utility as there is during the creation of an Automated Attendant. I can’t speak for you, but I was curious to know if I could just copy the WAV file to the mailbox? Where was the mailbox anyway? Now that you mention it, where are the voice messages.

ShoreTel has always had a folder entitled “Shoreline data”, the name a residual of the company’s old name, look and feel. Historically, this folder contained all of the information you would need to have available to restore a crashed server from bare metal. The later releases of ShoreTel have moved configuration files to a MySQL database, but you still need to have this folder to do a system restore. The folder, among other items, contains the voice mail structure of your deployment and the actual voice mail files for each individual mailbox.

In the VMS folder, you will find two folders: “Message and ShoreTel”. The Message folder contains actual voice mail messages in ShoreTel WAV format; and the other folder contains a list of folders that match the number of each mailbox on the ShoreTel deployment. Each VM box folder contains a WAV file for the mailbox name and each greeting recorded in that users mailbox. The greetings have easy to recognize names like 115Greet01_01.wav which represents the Standard Call Handling mode Greeting. If you re-record your greeting you will create a new file named 115Greet01_X.wav, where X is the revision number of the recording.

There is a also a Mailbox.DAT file that contains system configuration information and the unique ID of every message received by that particular voice mail box. The actual voice message, however, is contained in a separate folder appropriately named messages! In this file you will find a unique message WAV file that is the actual voice mail recording. It will have the format 1K0VGJSGI.wav where 1K0VGJSGI being unique message identification. There will also me a matching 1K0VGJSGI.msg file that acts as an index pointed to by the unique message identification written to the DAT file in the individual voice mailbox folder.

ShoreTel has a number of debug and diagnostic tools that can be used to assist in administration and troubleshooting. The CFG.exe program is a useful tool for obtaining information about mailboxes, voice mail servers, phonebooks, automated attendant DNIS maps and other specific voice mail box configuration data. Using CFG you can turn on message waiting lamps, have the voice mail system dial specific extensions, list message details, purge and restore messages and generally manipulate the voice message structure. The three part video clip details all of this information for your education and enjoyment!

Trouble Shooting ShoreTel SGT1 Caller ID

Posted on November 13, 2009 by DrVoIP

Caller ID is an interesting area and we see a variety of client request regarding this functionality. On analog lines, there is not much room for configuration. Generally this information is transmitted as FSK (i.e. modem tones) in either the SDMF or MDMF format, in the silent portion of the phone company “ring cycle”. For this reason, if you answer an incoming call before the ShoreTel has an opportunity to capture the CID information, you may not see it displayed. Unlike a PRI, outbound caller ID is controlled entirely by the phone company on analog lines and ShoreTel can do nothing to change what is displayed when you call out of the system. Sometimes, if you have a number of analog lines, the phone company displays a different Caller ID on each line! If you ask nicely, and the moon and starts are in perfect alignment with Mars, the carrier might agree to have all of your analog lines display the main Billing Telephone Number or BTN of the client account. At the end of the day, outbound caller id, is what it is on analog lines.

On PRI lines, we have more control over what is displayed when you place a call to an outside party. Generally, in ShoreTel you can display either the main PRI number of your personal DID number. We have been able to spoof the PRI D channel and display any phone number you may want on an outbound call, by configuration of the Caller ID field in the Shoreware Director administration portal under Individual Users.

We are often asked if it is possible to display a different outbound caller ID on a call per call basis. Unfortunately, unless you are willing to reconfigure the Caller ID field this is difficult, but not impossible to do. ( I know at least one police department and a half dozen credit and collection agencies that do this when the called on suspects might not answer the phone unless they know that Mom is calling)! Sometimes a company has multiple Brand names or company names that they are using when they place phone calls. To enable call by call, outbound CID change, we create Bridged Line Appearances or BLA’s. These BLA’s can be configured with a different called ID and the client can select the appropriate line (read Brand) to generate the correct CID on a particular outbound call. As an aside, we note that the carriers are getting more particular about D channel spoofing of CID on PRI calls. On SIP trunks it is all but impossible. The Carriers now insist that the displayed number must be a number that is within your BTN range. This limits spoofing.

Trouble shooting inbound (or outbound, for that matter) Caller ID calls on a ShoreTel PRI is fairly straight forward. Minimally, you can use the Trunk Test tool to witness the caller ID of an inbound call. To tap the actual D channel messages sent by the carrier to your ShoreTel SGT1, you will need to setup a capture. To do this, you will need to take the following steps (see video below):

(a) Turn off the Telnet Security Shell via the ipbxctl command

(b) Telenet into the ShoreTel SGT1 switch;

(d) For PRI use mpm_debug_mask=0X40 for called ID and Name.

Unlike the early versions of ShoreTel debug routines, the CID and call setup information is reasonably intuitive to decipher. Traces can also be used to figure out who hung up on who and other carrier CPE shoot out questions. These are useful trouble shooting tools.

Lastly, we need to make sure we understand the difference between ANI (automatic number identification) and Caller ID. ANIS is tariff differently and is not subject to the same blocking restrictions as caller ID number. Generally, if you are paying for “toll free” numbers, you want to know who is calling! The carrier delivers the information in a format that looks like <DID> <DNIS> * <ANI> * <DID/DNIS> and the SGT1 can note the *delimiter and sort this out. You should also be aware that ShoreTel will attempt to route the call based on a selection priority that starts with DNIS, DID, Extension and finally Tandem Trouncing. If no match is found, the inbound call will be routed to the “destinations” specified for the trunk group, with the automated attendant being the default.

Trouble shoot “one way media” with the ShoreTel “phonectl” command!

Posted on November 8, 2009 by DrVoIP

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:

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.

ShoreTel Route Point Configuration

Posted on October 31, 2009 by DrVoIP

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.