The ShoreTel Prefix Option

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.

ShoreTel Contact Center Overflow Concepts and Direct Calls to Agent!

I would like to kill call center challenges with one blog!   In many call center environments, it is possible that an agent has a Direct in Dial (e.g. DID) number that a client might call and bypass the entire call center process!   For a call center manager, this is very frustrating!  You create a Contact Center to organize the flow of calls to your Technical Assistance Center, and clients by pass the process by calling your Agents/technicians directly!

Clearly, you can eliminate this by not giving DID numbers to Agents, but we end up doing this to facilitate an orderly problem resolution strategy.  You might give a client a “homework” assignment and ask them to call you back.   They might object to being put at the back of the queue again, so you give them a DID number that gets them directly back to you.  The challenge is, that this call would not be accounted for in your contact center reporting!   So how then do you provide this feature and also create a mechanism for enabling your contact center to capture all calls for Agent Performance reporting?  One answer is to establish a “service” that has only one Agent in it!   Then build out a DNIS/DID route point to IRN relationship that brings that DID number into the call center and routes it to the Agent.

Actually, it is not a bad strategy!   The Contact Center can now account for all calls, even the ones that reach your Agent through a DID number and you can apply normal Contact Center routing tools like “overflow”, which brings me to my second point!   Is it possible to overflow calls to more than one other group?  Based on more than one overflow time in queue?

The Contact Center provides a wide variety of methods for handling callers in queue awaiting service.   One of the more interesting concepts is the ability to “overflow” a caller from one group to another group based on the amount of time they have been waiting in queue.   This contact center parameter is set within the “service” and can be found in within the tab labeled “Overflow”.

In figure One below, you can clearly see that we have a number of services defined, including a service named TAC1.   Let us assume that this is a technical service group and that TAC1 is comprised of Agents/technicians that include Agent Gandalf, Kipling, Regan and Jack.      You can also see that a service has been enabled by the name “Direct Kipling”.    This service was created to enable callers to Kipling’s DID number to be brought into the Contact Center, and routed to Kipling even though they did not enter through the TAC1 service.   Hopefully, we can now count the phone calls Agent Kipling is handling that otherwise would not be reportable!

ecc_figure_1

In Figure One we can also see that we have set an “Overflow” counter that,  should anyone be in the Kipling Queue for 10 seconds they will overflow to the TAC1 queue.  What is interesting is that when you overflow in the ShoreTel Contact Center,  you don’t leave the queue you are in, you basically add another queue containing agents that have a cumulative effect on the call.    Should that “overflow” not result in an available agent and the caller continues to wait for service, you can actually set a second timer that would “overflow” (e.g. expand the number of agents ) to yet another queue.

In Figure two, you can see the original call in the Queue for Kipling.  After the pre-configured overflow interval is met, the call is distributed to the “overflow” queue but is also available to the original queue.  You can see this in Figure Three, by noting that the call is now in queue in both the Kipling and TAC1 queue.   In this way, if an agent becomes available, in either the original queue or the “overflow” queue, the call will be answered.   Had we set up a second interval timer in the Service, we could expand the number of Agents to include the additional group specified by that timer.  This is one of the more interesting, if not misunderstood capabilities of the ShoreTel “overflow” concept!

ecc-figure-21ecc_figure-31

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

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

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

Putty Telnet into ShoreGear SG50V/SG90V

We had a lot of requests for examples of telneting into the SG Voice switches, so we though we would do a quick video on that process. The V switch is a very different animal from the rest of the SG family. Basically, a small Linux server lives inside the switch and contains a Flash memory card to hold Automated Attendant and Voice Mail for users assigned to that “server”. There are some characteristics about the V switch that you should know and we have tried to summarize them below. One of the most important characteristics, is that a V switch MUST have a time source or bad things will happen!

The entire telnet process into this switch is different. You can find your way down to the subdirectory that contains the famous IPBXCTL security shell and run it using the normal command sequence. You will see the “telnet enabled” message, but you will pull you hair out before you can telnet into the V switch. To get inside the switch, you will need to use an SSH client like Putty. You will also need to log in as either the Admin or the Root users. The Admin gets you to a safe menu configuration option and you should have no problem configuring the switch. Remember, you have to have that NTS in your configuration! Log in as the root user however, gets you a more powerful set of trouble shooting command and enable you to back up the Flash card, and to some other debugs that you can not do from the admin user.

The video clip below walks you through the process. Here are some of the highlights we have discovered working with the V switch,

· Limited media stream capability.

· 1U Half Width Switch

· Voice Mail stored as 8-bit WAV files from G.711/G.729

· Switch can negotiate ADPCM but can Not proxy G.729

· Switch runs under Linux (not VxWorks)

· Voicemail Switch uses Qmail not SMTP and does not support SMDI

· SG90V supports 90 voice mail boxes

· 1GB Compact Flash stores about 1500 minutes or 15 minutes per user

· Full CF Card = “voice mailbox full” message

· Holds all Automated Attendant Messages?

· Store prompts for up to four languages

· At boot, requires connectivity to HQ server for configuration

· Once operational, does not need server connectivity for VM/AA

· V switch MUST have NTS SMTP and FTP resource

· Console port = Linux Shell STCLI is default

ShoreTel SIP Trunk Configuration Parameters for Level 3

Generally, we do not fill out forms given to us by Carriers.   Most Carrier forms use nomenclature that is “Marketing Speak” and not technically driven.   It seems we have 100 different ways to refer to a TDM with PRI signaling and only one of them means anything to an engineer.   There are a variety of new delivery methods being offered to clients for PRI service and it is important to understand exactly what type of circuit you are actually being given.    A PRI may in fact be a SIP trunk from a Softswitch, through a CISCO IAD with a TDM interface for your SGT1.   Not necessarily a bad thing (though you should expect problems with Fax service) but it is a hybrid circuit and not a traditional TDM T1 to a circuit switched central office.   We are always eager to assist the client by speaking with the carrier and having a dialog as to the exact nature of the circuit, but we steer clear of filling out the forms they expect their new customers to complete!

Recently, while planning the implementation of a ShoreTel IPBX with 230 SIP trunks, I  had the experience of pulling together answers to L3 request for configuration data.  With the help of  Rod Davis, Juan Rubio and Steve Weinstock we were able to respond.   To my surprise, this time there was not a single marketing expression in the document!   The questions were specifically engineering oriented and designed to understand the capabilities of the IPBX that the SIP trunk service was being ordered to support.    I though it would be interesting to share that information with our readers.  The IPBX is the ShoreTel and the assumption made in these answers is that the ShoreTel is being front-ended by an Ingate Separator.   Here are the SIP configuration questions and answers:

level31

How to set up Backup for ShoreTel VG50 and VG90 V siwtches!

Both models of the ShoreTel VG90 and VG50 are availabe in V switch configurations.   The V switch configuration enables you to provide local voice mail and autoamted attendant functionality to a smalll site economically.  Compared to the cost of adding a distributed voice mail server, the SG50V and SG90V are economically viable alaternatives that should be considered as you plan for resilency and site continuity during a WAN outage.

Due to the CF card capacity, daily backup of  voice mail and automated-attendnat is advised.  When automatic backup is enabled in the ShoreWare Director, it begins immediately after the server completes its daily house-keeping operations.  Automatic Backup Stores Voicemail, Auot Attendant Data and switch  log fiels to an FTP server.  After completion of the daily file-system cleanup taks, the switch begings automatic backup.  A time stamp is appended to the name of the files copied to the target server.

Automatic backup provides a source for the most recent days voice mail and the other data in the event of a system failue.  It is not intended to be an archive of voice messages or a sourc fo retrieving deleted voice mail.  The following silent film clip walks you through the process of setting up an FTP site and properly configuring the ShoreWare Director for V switch backup!

How to Telnet into a ShoreTel phone

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.

Switch Connectivity Diagnostic

Most ShoreTel System Administrators learn early on that the “Quick Look” link in the ShoreWare Director is your best friend! After all, telephony trouble indications are easy to spot: Green is good, Red is Bad and yellow means “something needs attention”. At the first report of a trouble indication, a System Administrator will bring up a browser and get to the log in screen of the Shoreware Director portal. Quick Look, Under the Maintenance section of the administrator portal, provides an immediate snapshot of what is going on in the system. If you see any RED at the HQ level, you can drill down and find the site and switch that might be the source of your problem.

What happens when you look and you see Green?All is good!Why am I getting user reports of inability to complete a phone call?The very best next step for you to take is to click on the Switch Connectivity link under the same Maintenance section as Quick Look.The switch connectivity screen will illustrate any connectivity issues between switches on the network. It is very possible that the HQ server “sees” all is well and reports Green, but individual switches served by DVM’s, for example, do not see each other.By pinpointing the intersection of switches that can not communicate with each other, you will generally find a network or default gateway issue that is causing your negative user reports!As useful as the Quick Look may be, the Switch Connectivity page is a more useful diagnostic for locating network based issues.

switch-connectivityFor more detailed information about a switch, place the mouse cursor over the connectivity cell in question and status information will be displayed in the status bar at the bottom of your browser!  Green is Still Good and indicates the Switch is communicating with the other switches in the system.  Yesllo indicates that the switch connectivity is unknown because it can not communicate with TMS and RED indicates a complete loss of communications with the server!

The missing ShoreTel Beep!

In both ShoreTel Release 8 and 9 there is a very interesting behavior that will ultimately bring a client call to your support center.   The behavior is most obvious in a multi-site deployment in which there is only one HQ server providing voice mail services.    A call to a user at a remote site is RNA (i.e. ring no answer) transferred to the voice mail system.   The call entered the system on a PRI at the remote site and is then transferred across an MPLS WAN to the HQ server.   The caller hears the greeting: “I am not here, at the beep please leave a message”.   The caller dutifully waits for the “beep”, but it never comes.  What happens to it?

The fact of the matter is the “beep” was in fact played, but the caller did not hear it.   This has to do with the use of the G729 Codec on Inter site calls in this scenario.   The G729 is distorted to the point that the caller can not hear the beep.   The distortion appears to only be related to the implementation of the G.729 codec on the virtual soft switch.  As a troubleshooting step, I used a different phone system and an IP phone that was set to only use G.729.  When we called the HQ virtual soft switch over a local PRI trunk where ULAW was being used from the PRI switch to the HQ server, we heard the voicemail beep without distortion (through the G.729 codec as implemented on a different PBX).  It is only distorted when the virtual soft switch is trying to do G.729.

Outlined below are two WAV files of the normal beep (ULAW) and the distorted beep (Softswitch G.729).  We have also attached a visual representation of the audio files.  The distortion is audibly and visibly clear.  Our thinking is the “beep” is to short and to high a frequency, but we are not developers!  Currently, the only known fix for this is to change the Codec to G711.  That fixes the issue, but it may have a negative impact on your WAN plan!  I am sure there is a fix in the works back at the ShoreTel Mother ship, but we have not seen it yet.

waveforms