Category: Voip Service & Solutions

Configure ShoreTel for Redundancy, Resiliency or Business Continuity?

Posted on by DrVoIP

Of late we have seen a growing interest in building “disaster recovery” solutions for both the data and the voice applications so critical for business operation.  First, we need to make sure we understand the difference between redundancy, resiliency and other configuration options to assure business continuity.  Many more installations now include the use of a remote “collocation” facility as an key  component of the installation plan.  What is the best way to configure a ShoreTel HQ server, for example to provide for continued operation under a wide variety of options.

The subject of redundancy is almost amusing at times.  How much redundancy is reasonable and appropriate?  You can have all the redundancy your budget can fund, but at the end of the day are you able to continue the business operation in the event of a catastrophic event.    Clearly, two power supplies are better than one.  If they are both plugged into the same commercial power outlet, however, it really will not matter how many power supplies you have if you lose commercial power!  Again, we need to focus on what are we trying to protect?

Redundant servers?   Some HQ servers have been configured with “double take” enabling a hot standby server to take over in the event of a primary server failure.    Candidly, we do not see the benefit of hot standby server swaps in the ShoreTel architecture and it is a nightmare to administer, backup and restore.  The cost of the solution outweighs the benefits and there are other configurations that are more cost effective and work just as well.

For example, there is no law that says you can not install a ShoreTel Distributed Voice Mail server at the same level as the ShoreTel HQ server.   Actually, this works just fine!   Install the servers at the same physical location, or put the HQ server in the remote “collocation” facility.  If they are installed at the same “logical” level (i.e. appear on the same level in the Shoreware Director, either server can handle the load.   Generally, you would put all of the users and switches for that site under the DVM and use the HQ as your “fail up” and proxy solution.   Nothing wrong with this configuration, it is cost-effective and easy to administer.  From time to time you might hear ShoreTel say “ please wait while I connect you to the correct server” but even that can be managed.

ShoreTel HQ has three services that are not distributed: Route Points; Account Codes and Workgroups.  If you lose the HQ server, you will lose these services, but generally, that is a small price to pay for this level of resiliency!   ShoreTel Version 10 promises to distribute these services, so there is no reason not to configure this way and achieve full survivability given the building is still standing.

You don’t have to think very long about a Katrina or Haiti, especially if you live in California!  It is only prudent to not only plan for some level of “redundancy”, but also to plan for how the business would operation if we could not get into our building!  If we put the HQ server at the “collocation” facility and we provide for Trunk Lines and “dial tone”, we can balance this possibility.   The issue is, that if the building housing the people becomes unavailable, users can still log in and route their phones to cell phones or make use of RDP to access their Call Managers.

The “collocation” option often requires a trade-off between bandwidth and trunk lines.   You can put all your trunk lines at the colo, in which case every call made from the sites, will traverse a WAN.  So moving the trunk lines to the colo increases resiliency but also drives up your WAN cost.  At the end of the day, it is most likely some combination of bandwidth and trunk lines spread between the facilities.  In either case, you will work with your carrier to enable lines to be repointed in the event of an outage.  This is a bit more challenging if you are in New York and your collocation facility is in Phoenix, but it can be done.

We are experimenting with the use of SIP trunk facilities at the Collocation site.  Generally, this can be more cost effective especially if you can get an agreement for a burstable SIP pipe.  You may not want to pay for T1’s at the collocation if you are only planning to use them for a disaster situation!  SIP also enables you to be generally independent of your physical location.

It is a sign of the times that we spend so much time planning for “what if” scenarios, but being prepared is not only prudent but appropriate.   Have a comment on this blog?  Email:drvoip@drvoip.com

DisasterRecovery

Why move the Auto Attendant into the Contact Center?

Posted on 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!

Fun with ShoreTel Voice Mail

Posted on 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!

PDF and Email those ShoreTel Historical Reports!

Posted on by DrVoIP

“Historically”, excuse the pun, we always had a challenge with ShoreTel Contact Center Historical report!There were two issues.First, though you could schedule a report to be run automatically at a present time, you had to chose between printing to a file or printing to an actual print device.If you choose to print to a file, you could not set the path for any location other than that set by the default path of the ShoreTel Contact Center.Secondly, most Supervisors would rather have the scheduled report converted to a PDF and emailed to them!Automating the report is wonderful.Automating the delivery, however, was more important.

In Version 5.1 both of these challenges have been addressed, though a bit of “IT Magic” is still required.ShoreTel provides the path manipulation and email ability, but the GNU project provides the PDF conversion capability.You need to go to http://sourceforge.net/projects/ghostscript and download “ghostscript”. Once you have this software you will use standard Windows facilities to install a new “local” printer to enable the Ghostsciprt PDF printer! This is the first step, printing your Historical reports on a schedule and have them output to a file in the form of a PDF. Works like magic!

The second part takes advantage of the DESTINATION tab in the ShoreTel SCHEDULE option for Historical reports. After you create your Historical Report Template you then have the option to schedule the printing of the report, to a file or to a printer, To have the report emailed to you, you print the report to a file at a scheduled time. You then indicate that you want the report emailed and you complete a simple form that indicates who to email, who the report is from and what the subject of the report is. At the scheduled time, the report is generated, sent to a file through the Ghostscipt option to obtain a PDF and then the ShoreTel SMTP email option forward the email on to the intended recipient.  In 5.1 it is no longer necessary to separately configure the SMTP options.

Sometimes it is the really simple stuff that makes it a desirable feature. This new ShoreTel Contact Center configuration for Historical reports is among the most frequently requested capabilities we have heard among the installed base of Contact Centers! Kudos to the ShoreTel ECC development team for getting this done! Wonder if this will work on ShoreTel IPBX CDR reports?

emailreports1

ShoreTel PCM 9.1 Microsoft Installation Error

Posted on by DrVoIP

When installing the ShoreTel PCM 9.1 call manager software on a PC that has been upgraded to Windows XP service pack 3, occasionally there is a Microsoft Installer error that prevents the ShoreTel software from being installed. The error is “Error 1720 – A script required for this install to complete could not be run”. The installation will then fail requiring the issue to be corrected and the installer to be ran again. This is caused by an issue with the Window XP service pack 3 install that sometimes will corrupt certain binaries used by the OS. Microsoft recommends a reinstall of the “Microsoft Distributed Transaction Coordinator” to correct the issue. This challenge is usually only noticed in a handful of service pack 3 machines where the corruption is present. http://support.microsoft.com/kb/891801

ECC Medical Applications

Posted on by DrVoIP

With all the talk about “health care” you would expect growing demand for  more application integration for this particular industry vertical!  The ShoreTel Enterprise Contact Center can process “dial lists” that enable the system  to make outbound phone calls.   The “dial list” typically gets a list of phone numbers from a MySQL database that can be populated by some other application, like scheduling software.   It would not be out of the realm of possibility for the ShoreTel ECC to be used to confirm appointments or to generate a broadcast message that could be confirmed by a script that captures DTMF responses, including the ability to talk to a live person!

The ShoreTel Enterprise Contact Center, though primarily and inbound call processing solution, can be applied to do outbound campaign dialing.   In addition to the native SQL scripting tools,  the system  can integrate with a wide variety of applications through either OBDC, XML or “triggers” and we have had experience with each of these options.    There is a young man up in the bay area, Houston Neal,  who has been writing a bit about Health Care Applications and you might take a minute to check out his recent article on this subject:  Seven Great Applications for PBX systems in Medial Practice.

The ShoreTel Prefix Option

Posted on by DrVoIP

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

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

The second option is less obvious and many ShoreTel field installation technicians will not be familiar with the option. Out of the box, ShoreTel supports site based Prefix Dialing. In our example, we would leave both Company A and Company B with a HQ server. They would appear to be two separate systems. The use of the Prefix dialing, however, makes it possible to enable the extension to extension dialing between the systems. Through the ShorewareDirector web portal, you would select the Dialing Plan from System Parameters. The dialing plan would enable you to select a digit for extension dialing, with from 1-7 prefix digits. In our small example, we might make use of Digit 7 with a prefix of 2 digits, allowing us to create 99 sites.

When you exercise this option, you will see a new field appear in the SITES definition in the ShorewareDirector portal. Entitled “Extension Prefix” the field enables you to assign a two-digit SITE ID to each site you create. As you assign users to SITES, their extension numbers become the SITE ID + Extension number. Given that we have a WAN solution in place, we can then establish SIP Tie Trunks between Company A and Company B. The Trunk Group that defines the TIE LINE would have an OPX (off premise extension ) list that defines the extension range that “lives” at the other end of the TIE line. Company A might have a prefix of 77 and Company B might have a prefix of 78. Users in each system, even though they were previously defined with a three digit “dial plan” would now show 77-123 or 78-123 when you reviewed their individual USER configuration in Shoreware Director. Assume further, that both companies had similar “dial plans” meaning that they had the same extensions assigned in both companies! The extension prefix option working as a site ID, enables both companies to keep their extension numbers.  From within your site, you only dial the extension digits.   You dial the prefix digits + extension number to reach someone in a different site.

site-id1

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

More on ShoreTel LLDP – follow up to previous blog post!

Posted on by DrVoIP

This is a follow up post to an earlier post on LLDP-MED. VoIP phones on the market today follow the same basic boot and operations process:

1 – Wait for an LLDP packet from the Ethernet switch

2- Send a DHCP discovery packet to find the DHCP Server

3- Send a DHCP request to the DHCP server to get an IP address

4- Send an LLDP-MED packet to the Ethernet switch

5- Wait for an LLDP-MED packet from the Ethernet switch and read the Network Policy TLV to get the VLAN ID, L2 priority and DSCP value

6 – Download applciations and software from the “call manager”

7 – After configuration , voice packets are sent as tagged frames and data packets are sent as untagged frames

The ShoreTel implementation of LLDP seems to follow this process only after step 5, the result of the IP Phone learning LLDP by having its firmware configured. In other words, a phone out of the box is a hung of iron with no inherent ability to define itself as an IP phone to an LLDP enabled ethernet switch. The ShoreTel phone will still require an intial boot in the native VLAN and then reboot in the voice vlan, where it will then download its firmware. The real value here, is that once this process is “learned” by the ShoreTel phone, should the phone restart for any reason in the future, it can start at step one above. LLDP in ShoreTel is a version 9.1 feature enhancement not available in earlier releases of ShoreTel.

update 2/15 see  article at Support.DrVoIP.com

How to cause a ShoreTel phone to dial from within Outlook

Posted on by DrVoIP

We see a lot of request that can be summarized as   “can we dial from within<(insert your favorite application here>?   Outlook, for example, has an ability to let you select the ShoreTel TAPI line so that you can dial from a Contact.  Here is how you set it up.  First, in the tool bar of the Outlook Contact, you should  see a PHONE ICON.  Selec the Icon to open configuration options:

Outlook Tool BarThe select the “Dialing Options”.  In the new box that opens, you will see a drop down box that allows you to select the ShoreTel  TAPI line with Outlook should use to dial  (this would be the same for any other applicaton that supports TAPI based dialing).

Select TAPI lineIf you see the call is attempted but fails, you may need to check the “Phone and Modem Options” in the Microsoft Control Panel to ensure the system is setup for the appropriate area code and Trunk Access code.

Phone and Modem OptionsOther than that, there are no other settings and the ShoreTel should “smile and dial”!

How to Telnet into a ShoreTel phone

Posted on by DrVoIP

A typical trouble ticket might sound like “when another extension calls me, I can hear them, but they can not hear me”!  Actually, one of my personal faviroites.  Over the years I have come to learn that this is usually the result of one of two issues: someone has the wrong default gateway; or port 5004 is being blocked by some firewall in one direction.  As we move more and more toward SIP and media streams move away from a dedicated port, this issue is almost always a network configuration error.

So which device has the wrong default gateway?   That takes some dedective work.   Generally you will telnet into the ShoreTel SG media gateways and check the configurations.   Media stream between phones generally do not need an SG switch beyound call setup.  The media stream, once the call is setup, is between the two phones.   For this reason, you will want to tenet into the phone and “see” the network from the phone’s percepective!   To do this, you will need to know the ShoreTel methodology and process.

Security on the SG switches and phone, requires that you start the process from the ShoreTel HQ server.   There is a specific subdirectory that you need to be in to launch the various utilities.  This silent viedo walks you through the process of using one utility, phoneCTL, to telenet into a phone and look around.