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.

PDF and Email those ShoreTel Historical Reports!

Posted on October 26, 2009 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?

To VLAN or not to VLAN, that is the question!

Posted on October 15, 2009 by DrVoIP

An assumption in this blog is that if your company has a “network administrator” on staff, you have a network that is large enough to require constant “care and feeding”. As such dumping a bunch of VoIP phones onto your network without VLAN’s would never happen. After all, the fist job of a network administrator is to make the network broadcast space smaller and smaller. That is why we subnet! Take a typical Class C network with 100 network devices on it and dump another 100 VoIP phones in that subnet and you are asking for trouble if you don’t VLAN. To suggest you don’t need a VLAN or at the very least, a separate subnet is just plain silly.

Did you ever hear the expression ‘fences make good neighbors”? Well the same concept applies to networks and VLANs make network applications like voice and data, excellent neighbors! Lets assume those 100 desktop computers are in the 192.168.1.0 /24 subnet and you created a new 192.168.2.0 /24 network for your VoIP phones. In a ShoreTel deployment, you will have personal call managers installed on the computers in one network that need to get to the ShoreTel server and switches in the other network. How are you planning to do this? Use the old “router on a stick” solution (send all my LAN traffic up one switch port to a router and back down again)? Let me help you here, no! You are going to set up VLANs and do inter-VLAN routing at backplane hardware speeds on that new POE Ethernet switch you purchased to support your VoIP deployment.

Data networks have become “mission critical” for even the smallest of companies today. Just unplug someone’s Internet connection and you will quickly find out just how important the “network” has become! Start bogging down the network with Voice, Video and Streaming audio and you will quickly learn the value of VLANs. We invest billions of IT dollars on firewalls, spam ware and website filtering software so why would anyone suggest that a VLAN is just to complex to bother with? By the same (excuse the pun) token, why would someone suggest buying a new POE Ethernet switch that was not VLAN capable?

Data networks need to be described within the context of the protocols and business applications that are running on them. Big or small, we continually find that VLANs are an essential component in the maintenance of proper network hygiene. Imagine even a small VoIP deployment in a company enraged in video animation and you can quickly realize that it is not only how many devices I have on the network, but how my network is being used that will determine the qualify of voice in this deployment. We need to make sure that streaming video over even our LAN, does not negatively impact our VoIP deployment. To do this, we need prioritize voice over data and that means we have to establish QOS. To enable LAN based QOS you have to VLAN, because the class of service markings live in the VLAN tag!

Put your VoIP deployment in a multi-site environment with WAN links and the VLAN discussion now moves into the realm of “must have”. Routers use the TOS byte in the IP header to provide enable QOS. As an aside, ShoreTel had the advantage of enabling Transport layer QOS as the VoIP media stream as always on port 5004. With the move to SIP, this advantage has been minimized as the media stream now moves unpredictably over some 16K ports. We can pass QOS information to our WAN links through a variety of strategies, but VLAN’s are an essential element of that strategy.

At the end of the day, unless you have a network that is so small you are running Vonage as your VoIP solution, you need to VLAN! Make sure that your VoIP deployment includes an assessment of your network and that you graphically understand how the network is utilized before you deploy voice. As your internetwork becomes more essential to your network, VLANs will surface into high relief on your radar screen. Consider that your shiny new ShoreTel now provides for Internet messaging and desktop Video as part of its advanced feature set, the idea of deploying a solution without a VLAN is just plain silly.

The ShoreTel Workgroup Monitor Kicks Butt!

Posted on October 13, 2009 by DrVoIP

As you can tell from our video library and blogs, we are very excited supporters of the ShoreTel Contact Center! You can not find a more feature rich or cost effective solution to call routing, email routing and web collaboration! To be fair, however, ShoreTel has always been ahead of the curve with “call center” like functionality. Out of the box, the ShoreTel IPBX has an amazing set of features that can fit just perfectly in the small “call center” model. It may be easy to define the difference between a “call center” (i.e. phone calls only) and a “contact center” (i.e. voice, email and chat); but it is much harder to differentiate a “workgroup” from a true “call center. ShoreTel clearly believes there is a definable difference and for that reason has always had an impressive call routing option humbly named the “Workgroup”. Not the “call center” but the “Workgroup”! Going way beyond simple “station hunting”, the ShoreTel “Workgroup” enable scall queuing, Agent “log in” / “log out” , “wrap codes” and provides a rich set of easy to generate performance reports.

ShoreTel has recently introduced the “ShoreWare Workgroup Monitor”. This amazing software package provides real-time, color-coded, graphical views of the the Workgroup and is an optional feature to the already powerful ShoreTel Workgroup feature set. Compatible with Version 7.5 and up, this software enhancement enables call center management to both optimize and monitor call center performance.

There are three software components: an application that is loaded into the Shoreware Director or any of the distributed voice servers; a client application that is loaded on the Supervisors desktop and any version of the ShoreTel Call Manager. Key features of this optional software package enable a Workgroup Supervisor to create a standard workspace display or “canvas”. This “canvas” could be displayed at the desktop or on a “wall board” and provides many of the real time characteristics of a full blown Call Center solution. With this software you now have the ability to set color coded threshold displays and audible alerts. We are particularly excited about the ability not only to see abandonded calls, but to click-to-callback! (Now admit it! How kool is that)?

Supervisors can drill down on the Workgroup of interest, with an easy <> window arrangement. You can set the threshold alerts for the selected Workgroup to enable Yellow or Red alerts for Calls in Queue, Maximum Wait time and Average Wait time. The “at a glance” window gives you a snap shoot of each Workgroup, indicating the number of calls with longest and average call holding times. How about a “trend” analysis? Yup, we got that! For those spacial database managers with holistic mind sets, you can replace the rows of linear figures with a color pie chart to see Agent status!

The ShoreTel Workgroup feature set, built on the f the standard out of the box ShoreTel IPBX, when combined with the ShoreTel Workgroup Monitor software option is a powerful call center strategy. It truly rivals any solution in the market at any price point. (Full Disclosure: ShoreTel does not pay me a dime to write this blog and ShoreTel does not support this site in any way. I really do believe this stuff). Keep in mind, we are talking about a single server solution, not multiple application servers and five acts of vaudeville to get this call center functionality. Just ShoreTel. Just simple.

Send me a note (DrVoIP@DrVoIP.com) and we will get you set up with a free 30 day trail of the Shoreware Workgroup Monitor!

How to create ShoreTel AA and ECC audio Files!

Posted on October 1, 2009 by DrVoIP

You can hardly install a Automated Attendant with out creating the Audio files! If you have looked at any of our videos on setting up the ShoreTel Enterprise Contact Center, you know that we urge you to create all of your audio files before you start setting up your Contact Center Services! Making recordings should be easy enough, but ShoreTel wants to have the wav file in a specific format: CCITT-mulaw, 8Khz, 8bit Mono. This is easy enough to create with something as simple as the standard Microsoft Sound Recorder, but the default wav format is some other format and you will need to “save as” clicking on the format change option!

There are actually three other strategies for recording voice prompts in the native ShoreTel format. Early versions of ShoreTel provided for a “preference” extension, used by the System administrator to indicate which phone would be used for making recordings. The System Administrator would set a specific phone phone for this purpose and when you pressed the Record button from within the Automated Attendant screen of the Shoreware Director, that phone would ring and you would then make your recording.

The resulting wav file would be stored in the Shoreline Data folder, in the prompts sub folder and it would be in the correct ShoreTel format. With Version 7 of ShoreTel, the option existed to enable Automated Attendant recordings by logging into the voice mail system, using the Automated Attendant greeting number as the voice mail extension number. This was an exciting possibility as it allowed recordings to be made remotely and on the fly as required to meet specific emergency or holiday requirements.

Unfortunately, the files that resulted from these two recording techniques had very unfriendly file names. When managing greetings through the automated attendant, it would be nice to have a wav file with a name that related to the greeting. As a result the best practice method of enabling ShoreTel recordings is to use your Personal Call Manager! By creating a recording using your Call Manager, you are able to name the wav file something useful and you are able to export the recording as in the appropriate format.

Over 15K ShoreTel desktops later, people are still asking me how to make an automated attendant recording! I though I would generate a short tech tip video and demonstrate all three of these techniques! Enjoy!

ShoreTel PCM 9.1 Microsoft Installation Error

Posted on September 30, 2009 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

More on ShoreTel V switches!

Posted on September 28, 2009 by DrVoIP

When installing a Shoregear switch, one of the parameters that you enable is to indicate which server is to manage this switch! Normally this is no big deal, but with the V switch, you need to pay attention to this parameter as it will impact your Automated Attendant and Hunt Groups.

Let us assume we have a V switch installed in Dallas, Texas which is in the CST zone. If this switch is managed by a server in the PST zone, then we need to adjust the schedules. When using a V switch in another time zone, which would normally not be managed by a local DVM, the site will need separate schedules applied to hunt groups and auto attendants. The hunt group schedule will need time expressed in the time zone of the HQ server (example: site is in CST but HQ is in PST, 8-5 CST would then be entered as 6-3 PST on the schedule for hunt groups). The auto attendant schedule will use the time zone of the application server (the local V switch) so the time can be entered in the local time zone.

The first time you set this up it will undoubtedly bite you! So be aware of this configuration issue and save yourself a service call from the impacted User Group!

ECC Medical Applications

Posted on September 21, 2009 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 September 16, 2009 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.

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!

Posted on September 14, 2009 by DrVoIP

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!

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!

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

Posted on September 10, 2009 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