Category: ShoreTel Configuration

What is new in ShoreTel 13?

Posted on by DrVoIP

There are a number of major enhancements to ShoreTel in Version 13. Most enhancements have been related to bringing ShoreTel SIP into compliance with the standards accepted by the SIP community at large. Though there are enhancements for other features like the SA-100, this release is notable for what it does NOT announce. The marketplace is demanding enough but the issue of having your development agenda driven by an outside company must be dreadful! In this case, Microsoft dominants many of the decisions that ShoreTel must make with respect to the priority of features and releases. So how tightly is ShoreTel bound to Microsoft? Why have they not followed the path chosen by CISCO and others to move to an “appliance” built on Linux?

Historically, ShoreTel server side functionality was driven by Microsoft. Simple issues like changing FTP port numbers between 32 bit and 64 bit servers might seem like trivia, but it is maddening for change management. Microsoft products continue to drop support for their older computing model that used CSIS and TAPI in favor of the Client Application Service or CAS model. We saw the first effects of this in Version 11 with the release of the Communicator for Web. In Version 13, CAS support has now been extended to Communicator for Windows. In fact, Version 13 ShoreTel no longer supports TAPI, CSIS or MAPI and for this reason ShoreTel will no longer run on Windows 2003! At the end of the day, how long until ShoreTel cuts its dependency on Microsoft completely? We think this is something that the company must do if not to remain price competitive, then to control its own product development priorities!

ShoreTel SIP meets RFC 3264 Compliance!

Actually, ShoreTel adopted SIP before any other major competitor outside the Asterisk community. The early adoption of SIP meant that ShoreTel had to design solutions before the community had solidified around a standard. Time goes by and here we are more than a decade later and SIP has had many changes, while ShoreTel’s Enhanced SIP was not in step with these changes. Version 13 is all about bringing ShoreTel SIP into compliance with key areas if SIP and making a SIP trunk feature equivalent to a PRI trunk. This is accomplished through compliance with changes in the Session Description Protocol and the creation of “Media Proxy Ports”.

SiP is used to setup calls. The actual media stream between the end points is handled by other protocols, namely RTP. When a SIP end point generates an INVITE it might send a session description (i.e. SDP) of how it would like the call to take place, indicating its capabilities and preferences. The other end might accept the INVITE with or with our modifications of the SDP thus the Offer/Answer definition of RFC 3264. ShoreTel historically had no way to deal with the SDP information treated this as an “INVITE with no SDP”. The usual response to this type of INVITE would be to send back a SDP, but ShoreTel generally responded with “Not acceptable here”. With the release of Version 13 ShoreTel will now be fully complaint with RFC 3264 and play nice with the other kids in the Offer/Answer game.

Once the SIP parameters have been established, the media stream is generally setup between the end points. This means that the actual voice packets are going between the two connected phones. Now if you think about this a minute, you will understand almost intuitively why features like Call Recording, Office Anywhere, Monitor etc. did not work on SIP trunks using earlier ShoreTel versions. If the media is streaming between my end point and your end point, who is listening for any DTMF tones that might indicate we want to activate a feature? How would you play Music-on-Hold?

Enter ShoreTel Media Proxy ports! These will be switch resources set aside to enable a point at which ShoreTel can mix or “mesh” media streams. This means that features that previously could not be activated on a SIP trunk should now work. On switches that can support Media Proxy Ports (not all ShoreGear switches can) you will find a new option in the drop down menu for configuration ports to enable “SIP Media Proxy”. The proxy is actual for one SIP trunk and a media proxy so it wipes out 5 SIP trunks or 5 IP phones. The ShoreTel 220/T1/E1, 220T1A , T1K and E1K can also be used to provide SIP media proxy functionality. You will find a new check box that allocates all configurable ports on that switch to this function. For this reason, currently a switch that supports a PRI can only support 20 channels. On the other side of the coin, you were replacing that PRI with SIP anyway right? The good news is SIP trunks will have feature parity with PRI trunks and these ShoreGear switches can be re-purposed.

ShoreTel will support “on demand” media proxy as well as dedicated resources. Change and configuration management skills will most certainly be tested here, as the configuration is non-trial. Music-on-hold for example will need to be carefully considered. Historically, MOH could be played by any switch in a site. If you want to play MOH to your SIP trunk you will have to use the ShoreGear switch that is configured as the media proxy. Other items of note are support for Digest Authentication and enhanced fail over detect. The ShoreGear switch can now provide registration credentials when presented with a CHALLENGE request. The ShoreGear SIP Profile now provides for the OptionsPing to test for 5XXX/6XXX network error to mark a trunk group out of service. Major enhancements in ShoreTel SIP!

The use of an Ingate like device is still a requirement. Candidly, a serious enterprise should not be implementing SIP trunks without some form of “border controller” so get over it. SIP Message Normalization, NAT traversal, Pinhole management, network separation and providing for more SIP Channels then you can get on one ShoreGear switch are reasons that you need a border controller. Currently all SIPTrunk certifications by ShoreTel have been completed with an Ingate in the equation.

There are a few changes to the System Administration Interface to facilitate the media proxy configuration. With the death of CSIS, TAPI and MAPI there are also some changes to the Windows Communicator. We will get a video posted soon! As always, comments are invited!

ShoreTel analog connections and the 66 Block!

Posted on by DrVoIP

It is surprising that in the 21st century we are still punching down copper lines! None the less fax machines, credit card devices, postage machines and security circuits still populate the installed base of telephone systems. If you are converting from a legacy phone system to a VoIP solution, on premise or hosted, you will have to plan for “analog” devices. A “best practice” for any VoIP phone system is to have at least one analog telephone company provided central office line, per site, attached for power failure and E911 operation. ShoreTel, for example, has conveniently made it possible for one “port” on a ShoreGear switch to cut through to another port enabling basic POTS operation during a commercial power failure.

The venerable 66 type punch down block is typically used to accomplish analog device connectivity. We like to think of the 66 block as the “border controller” in the analog world. You can easily separate the telephone company (read WAN) from the customer owned and operated equipment (read LAN) by removing the bridging clip that separates one side of the block from the other. VoIP or not, the 66 block is not going away. Phone technicians love 66 blocks, but IT technicians prefer “patch panels”? Unfortunately, the telephone company typically delivers the circuits at the MPOE or “main point of entry” downstairs in the basement! If you want to get it up to your patch panel, you are going to have to deal with the 66 block.

The basic components are the 66M1-50 split 25 pair block and wall mount bracket. The block is designed to cut down two 25 pair cables on each side of the block using an industry standard color code. Typically you would put your equipment on one side of the block and your station distribution on the other side of the block. Generally “cross connect” pairs act as the equivalent of patch cables, interconnecting equipment and devices. A “bridge” clip is used to connect one side of the block to the other side. If you are thinking ahead, you might use a “rat tail” cable that ends in a male or female amphenol connector to limit punch down and facilitate quick connect.

The ShoreGear switches have a male RJ-21X amphenol connector on the face plate. You will need a female or red amphenol connector to bring 25 pairs of copper out to your 66 block or patch panel. Optionally, 66 blocks can be obtained with an RJ-21X amphenol connector built in. For reasons nobody can explain, the Male connector has a Blue cap and the Female connector has a Red cap over the connector pins for protection. Beware of what sex your connector needs to be!

There is an industry agreed color code and sequence that defines how a 25 pair cable should be punched down. ShoreGear switches, however do not use all pairs. Each switch type has a different port pin out, so pay attention to your planning and installation guide. Additionally, not all analog ports are equal on a ShoreTel switch. There are three types: Universal, Fxo and Fxs so make sure you know what device you are needing to connect and use the correct port type. Universal ports will support either a Central Office line (Fxo) or a Station device (Fxs).

The video walks you through the details of connecting a ShoreGear switch to a 66 block, outlines various cable alternatives and details the color code! With the help of our friends at cable supply.com there is a detailed presentation on how to “punch down” a 25 pair cable on a 66 block. Enjoy and as always comments are welcome!

Enabling Chat on your Website with ShoreTel ECC 7

Posted on by DrVoIP

When someone is on your website, it is like they entered your store. Clearly, they have an interest in what you are about or they would not be there. It is at this moment that they are most receptive to learning about your product and services. Would you not like to know when someone hits your website? Better yet, would you like an opportunity to interact with a visitor to your website? If so, you want to enable a CHAT function, a link that says “connect with a company representative now”! Clicking that link opens a real time conversation channel with an internal human resource at your company! Research proves that the sales conversion rate on these transactions are without equal. Do you suffer from “shopping cart” abandonment? Maybe that last minute question could have been answered if your site had a Shoretel Chat function!

ShoreTel ECC 7 Website Chat

Contact Centers are different that call centers in just that way. In a contact center we know that people interact not just by phone, but by email and web interactions like Shoretel Chat. If you are running even a small contact center, you need to experience the high impact customer development strategy of enabling Chat on your website. The application is relatively straight forward, especially if you have a contact center operation. It is hard to find a company today that does not have some kind of web presence, so why not integrate the two?

The ShoreTel Enteprise Contact Center has a real time ShoreTel Chat function. Visitors to your online store can click on a link that immediately opens a chat window with the next available Agent. The same rules and options that govern your handling of an inbound voice call, can be applied to a Chat session. Chat sessions can be “queued” for the next available agent and will even show up on the Supervisors display as a customer waiting for service!

ShoreTel Website Chat Doesn’t end here

The transcript of a Chat session can be automagically emailed to the website visitor, and a copy can also be sent to the contact center for archive. Chat sessions are presented to your Agents in manner that is consistent with the behavior they employ on a voice call. They see the Chat session “ringing” in on their tool bar, click answer and a browser window opens up and they can are now in a real time Chat session with a visitor out on the world wide web. Agents can select from per-authored files and screen of information that can be sent through the Chat session with a mouse click.

Chat is among the most valuable customer interaction tools that you can add to your arsenal of sales aids. It can often mean filling a shopping cart that might have otherwise been abandoned! The film clip give you an overview of how to implement Chat using the ShoreTel Contact Center!

 

Install your ShoreTel Call Manager on your Apple iPad

Posted on by DrVoIP

On more than one occasion I have actually had to telnet into a clients router or switch using nothing more than a mobile phone!  Now, that is either an example of superior customer service or an indication of creeping insanity.   When you have to, you have to!   Sometime ago I moved to an Iphone and that actually makes RDP, VNC  or Telnet actually usable on a mobile phone in a pinch.

To say I think the Ipad is a game changer is an understatement.  If you analyze your computing habits you will find that you have two basic modalities: work and play.  At work, you are bent over and leaning in to your computer using a keyboard.  At play, if you could, you would be sitting in your favorite armchair surfing the web, watching yourtube and reading electronic books while updating your Facebook status.   This last mode, does not really require a lot of keyboard.  In fact the user interface that makes the Ipad so exciting is beginning to make you want to touch your Windows screen before you reach for you mouse.

It is the 21st Century and we are still keyboarding and mousing around?   The Ipad is redefining how the man machine interface will work.  Human gestures are much more effective than highlighting, dragging and dropping.  Ever consider how people use a phone?   They really want to poke buttons and lift handsets.  Mousing around is OK and many of us gravitate to all the features available to us when we integrate our phone system to our desktop computer.  The issue is, that word “desktop”.   The level of mobility that exists in business today, especially among knowledge workers and dispersed work groups is phenomenal!  Thus a growing dependency on Mobile devices.

Enter the Ipad. I admit it, I am a fanatical fan of the Apple family of computing devices, but I love this Ipad!  I finally took delivery on my Ipad 3G and am trying to figure out what I can and can not do with it.   I am able to do PowerPoint presentations on my Ipad using the Keynote App.   I am telling you, if you have to do a one on one presentation and you do it on an Ipad, you are going to get the order!

I found a great application named iTapRDP which I had on my iphone and it is now available on my Ipad.  This is a full blown RDP client that takes advantage of the “big screen” and additional real estate of the Ipad.   Now if i have to log into someones ShoreTel on the fly, I can do it with only the pain of a 3G connection, but with a full screen.    The next step was to just RDP into my own desktop and make use of my own ShoreTel Call Manager!  Now  using the “external assignment” feature, I have full ShoreTell Call Manager control from wherever I am, using my Ipad through and RDP session.

Come on, it is impressive to say the least!   No application required other than iTapRDP and I was running both ShoreTel 10.1 and an the Integrated ShoreTel Call Manager with ECC Version 6!    Sorry for the really bad video, but I am VoIP engineer not Oliver Stone (if anyone has a good Ipad Screen capture app, let me know)!

“Call flow” the callers experience when reaching your business!

Posted on by DrVoIP

Having managed 1000’s of telephone system deployments over my career, one subject continues to be the project “speed bump”.    You might think that the core issues of network configuration, WAN traffic planning, QOS and DHCP services might be the issues that cause a phone system deployment to go “sideways”, but you would be wrong.   Those issues clearly need to be defined, planned, developed and tested, but we always seem to get the technical issues worked out.  The speeds and feeds, the duplex and the QOS always seem to become clear and the system deployment is executed as planned.   I am a big fan of incremental, process improvement every day, every step of the way!

The area that always seems to require the most post cut support, however, is not the technical area.  It is the User Group area in general and the entire subject of “call flow” in particular that needs more up front planning to assure a successful “go live”.  When you are hammering out the details of the phone system deployment, we always seem to get the bits and bytes defined, but how about those automated attendant scripts?  For reasons that I can only summarize as “procrastination”, it seems that “call flow” is the last item to be implemented!   Not only has the “call flow” not been carefully considered, the scripts have not be written, reviewed or recorded.   It is one hour before “go live” and most deployment managers are scrambling to get a voice to record the Automated Attendant.

On my deployment system design check list, call flow is second only to the dial plan, as a mission critical design issue.    It is essential that project deployment managers engage the User Group early on, often and at each step of the deployment to assure success!  Clearly without the IT Director, the network definition is going to be less than easy, but without User group buy in on “call flow” you are headed for a disaster come “go live”.    I make interviewing the Company Operator a key part of our deployment planning and I make sure that there is a User group decision maker present at every planning meeting in which a “call flow” option is being discussed.

What exactly is “call flow”?   Each new caller to your place of business, will have an audio experience.   “Call Flow” is how we define a vision for that callers experience.    Do we want each new call answered by a real person?   How do we feel about the use of Automated Attendants?  Will a caller have a different experience based on the “time of day” or the “day of the week”?   Do all callers dial the same number?    Will the “live answer” point be an individual or a group of individuals and do we have a vision of what the caller should experience if the target live answer is not available?    Theses questions taken in their entirety define the subject of “call flow” and it remains one of the most important parts of your phone system definition and deployment.

There are a variety of tools that we can employ to create a “call flow”.  These tools include “automated attendant” menu’s that allow callers to “self navigate” through your phone system.    “Hunt groups” and “Work groups” can also be used with automated attendants to create “call flow” solutions that, while complex, are designed to assure a positive caller experience.   Taking the time to consider how a call flows through your company and planning for all the eventualities (e.g. busy, no answer) is not only essential to your customer service process, but it drives professionalism and demonstrates consideration for the calling public.  We have all been abused by Automated solutions, so take the time to consider the message you want to send to someone when they call your place of business.  Remember. “you only get one chance to make a first impression”.

ShoreTel Route a Call based on Area Code or Mood

Posted on by DrVoIP
“Can we route calls to a Workgroup based on the Area Code of the Caller”, asks our intrepid Sales representative!  “The prospect wants each Area Code in the country to be handled by a different Workgroup”.    Interesting question.   Now if we were talking about the Enterprise Contact Center, routing by Area Code would be easy, but we are talking about you basic ShoreTel IPBX and that type of routing is not obvious.     If we could get the Clients to call a different number based on which Area Code they are calling from, we could use a DNIS map to point the caller at a different Workgroup.  Though some phone companies actually have a value added service in which they can route a call to a different DID based on the ANI ShoreTel needs some additional functionality to achieve this level of call routing.
Maybe we could use ShoreTel “Call handling modes” to get the job done?   Features like “Personal Operator” and “Find/Follow Me” are offered to callers once they are in your Voice message box and they can be very useful by offering callers options beyond leaving a message at the beep!   Call handling modes, however, can only be applied after the call is answered!   What is required in the application described above, is the ability to manipulate a “ringing” telephone call and redirect that call before the call is answered.  So how would you route a call based on the callers Area Code?
ShoreTel has a new feature entitled “personalized call handling”.  This is a powerful feature that can be used to manipulate a phone call before it is answered.  You can route a call based on a number of conditions including a “phone number match”, the fact that you are already on the phone, based on the number the caller dialed or DNIS and even by the time of day or day of week.  Based on the condition you specifiy, actions can be executed that include forwarding teh call to a specific number or play a different ring tone.  If you select the condition “Phone number match”, for example, you can further define a specific internal or external number, and off-premise extension, a number marked as “private? or an “any external number starting with” and fill in the blank.
Imagine sending all incoming “private” numbers to “Dail a Prayer”!  You could really have some fun with this feature, but let us see if we can solve the above application.    Set this user up to foward calls to the NY Sales Workgroup, but looking at the Area Code of the calling number.  You can actually do this!  To make this work as in  the above application you will have to dedicate a USER to the applicaiton.   After you create the user and setup the “personal call handling” conditions and actions, you will need to change the DESTINATION of the incoming Trunk Group, to be this user.   Make sure you set the Call Stack for this user sufficiently high enought to handle the anticipated call volume.  The following film clip walks you through the setup of the Professional Call Manager to achieve the desired application results.“Can we route calls to a Workgroup based on the Area Code of the Caller”, asks our intrepid Sales representative! “The prospect wants each Area Code in the country to be handled by a different Workgroup”. Interesting question. Now if we were talking about the Enterprise Contact Center, routing by Area Code would be easy, but we are talking about you basic ShoreTel IPBX and that type of routing is not obvious. If we could get the Clients to call a different number based on which Area Code they are calling from, we could use a DNIS map to point the caller at a different Workgroup. Though some phone companies actually have a value added service in which they can route a call to a different DID based on the ANI ShoreTel needs some additional functionality to achieve this level of call routing.

Maybe we could use ShoreTel “Call handling modes” to get the job done? Features like “Personal Operator” and “Find/Follow Me” are offered to callers once they are in your Voice message box and they can be very useful by offering callers options beyond leaving a message at the beep! Call handling modes, however, can only be applied after the call is answered! What is required in the application described above, is the ability to manipulate a “ringing” telephone call and redirect that call before the call is answered. So how would you route a call based on the callers Area Code?

ShoreTel has a new feature entitled “personalized call handling”. This is a powerful feature that can be used to manipulate a phone call before it is answered. You can route a call based on a number of conditions including a “phone number match”, the fact that you are already on the phone, based on the number the caller dialed or DNIS and even by the time of day or day of week. Based on the condition you specify, actions can be executed that include forwarding the call to a specific number or play a different ring tone. If you select the condition “Phone number match”, for example, you can further define a specific internal or external number, and off-premise extension, a number marked as “private? or an “any external number starting with” and fill in the blank.

Imagine sending all incoming “private” numbers to “Dial a Prayer”! You could really have some fun with this feature, but let us see if we can solve the above application. Set this user up to forward calls to the NY Sales Work group, but looking at the Area Code of the calling number. You can actually do this! To make this work as in the above application you will have to dedicate a USER to the application. After you create the user and setup the “personal call handling” conditions and actions, you will need to change the DESTINATION of the incoming Trunk Group, to be this user. Make sure you set the Call Stack for this user sufficiently high enough to handle the anticipated call volume. The following film clip walks you through the setup of the Professional Call Manager to achieve the desired application results.!

ShoreTel Phone Security and the Terminated Employee ( a lesson in User Groups)

Posted on by DrVoIP
Recently a client discoverd that at terminated employee, gone for almost a month, was still answering his office extension from his cell phone!  We have so many technology options for mobility today that the HR deparment most be going nuts trying to keep the “exit interview” check list up to date!   Without commenting on the HR ramifications, IT system administrators have long had to contend with terminated employees and how to handle remote access, email and the other regular components of an advanced Information Technology.  With the advent of VoIP, most IT organizations have now had to add the telephone system to the growing list of security access concerens.
This blog and video clip was created to knock off a couple of concepts simultaneously.   First, adminstrators want to know how to configure permissions for different user types.   Clearly the folks who work in the call center are supervised by managers that require a set of features that might enable monitoring, barge in and call recording.  The Kitchen and Lobby phone do not need voice mail boxes and should only be enabled for extension to extension calling and 911 service.  Do we need to set up Account Codes for International dialing?   Who must enter an Accout code to make a phone call and who has Supreme being features?  The list goes on.    Do you allow your Users to reassign there extensions to external numbers, like the home office or cell phone?   If that employee leaves the company, do you have a plan in place as to how to manage that employees incoming phone calls?  This is where the concept of a ShoreTel Use Group can be exploited to rapidly nail down departing employees call flow.
The concept of a “containeer” as a mechnism for treating a class of users has been utilized as a programming convention since the first bit stream.   Microsoft System administrators will be immediatley comfortable with the concept, as will any IT professional who has system administration responsibility.   The concept is simple: rather than create a each individual and then list out their permissions, previldeges and class of service; lets “contain” them in a “group” and apply the permissions against the group.   This makes it easy to administer large populations of users who may share similar system facilities.  In ShoreTel, the concept of class of service, is defined and applied to a container named “User Group”.
Out of the box, ShoreTel has a predefined family of User Groups arbitraily but apptly named Exeucitve, Manager, Staff and so on.  Each user group contains a set of permissions defined as a Class of Service.  These services include permissions regarding the telephony features available to this user, the users dialing restrictions and also define key attributes about the users Voice Mail box.   In ShoreTel, certain features like “call forwarding” and “find me/follow me” require the user to have a Voice Mailbox, so understanding how these permissions are configured is essential to the creation of a secruity policy for your phone system.  If you allow the use of “find me follow me” or the ShoreTel “Personal Operator” funtion you might want to limit the range that those calling permission might include.  (If you want to talk to Mom in Italy, call my extension after hours and press zero when you here my greeting” is one of my personal favorites).
The video clip walks you through the process of creating a new User Group aptly named “Terminated Employee”.  This User Group then encompasses a body of restrictions that can be applied to a User, in this case a departing employee, with just a couple of key strokes.   The goal here is to nail down the employees call flow while you are working out the details of transitioning the employees work flow.    Clearly, you can just delete the user and be done with it, but normally business is not that simple.  Employees are part of Work Groups or  Hunt Groups that define a work flow and sometimes it takes a transition plan to get the details worked out.  In the mean time, we need to secure the phone!

Recently a client discovered that at terminated employee, gone for almost a month, was still answering his office extension from his cell phone!  We have so many technology options for mobility today that the HR department most be going nuts trying to keep the “exit interview” check list up to date!   Without commenting on the HR ramifications, IT system administrators have long had to contend with terminated employees and how to handle remote access, email and the other regular components of an advanced Information Technology.  With the advent of VoIP, most IT organizations have now had to add the telephone system to the growing list of security access concerns.

This blog and video clip was created to knock off a couple of concepts simultaneously.   First, administrator want to know how to configure permissions for different user types.   Clearly the folks who work in the call center are supervised by managers that require a set of features that might enable monitoring, barge in and call recording.  The Kitchen and Lobby phone do not need voice mail boxes and should only be enabled for extension to extension calling and 911 service.  Do we need to set up Account Codes for International dialing?   Who must enter an Account code to make a phone call and who has Supreme being features?  The list goes on.    Do you allow your Users to reassign there extensions to external numbers, like the home office or cell phone?   If that employee leaves the company, do you have a plan in place as to how to manage that employees incoming phone calls?  This is where the concept of a ShoreTel Use Group can be exploited to rapidly nail down departing employees call flow.

The concept of a “container” as a mechanism for treating a class of users has been utilized as a programming convention since the first bit stream.   Microsoft System administrators will be immediately comfortable with the concept, as will any IT professional who has system administration responsibility.   The concept is simple: rather than create a each individual and then list out their permissions, privileges and class of service; lets “contain” them in a “group” and apply the permissions against the group.   This makes it easy to administer large populations of users who may share similar system facilities.  In ShoreTel, the concept of class of service, is defined and applied to a container named “User Group”.

Out of the box, ShoreTel has a predefined family of User Groups arbitrarily but apply named Executive, Manager, Staff and so on.  Each user group contains a set of permissions defined as a Class of Service.  These services include permissions regarding the telephony features available to this user, the users dialing restrictions and also define key attributes about the users Voice Mail box.   In ShoreTel, certain features like “call forwarding” and “find me/follow me” require the user to have a Voice Mailbox, so understanding how these permissions are configured is essential to the creation of a security policy for your phone system.  If you allow the use of “find me follow me” or the ShoreTel “Personal Operator” function you might want to limit the range that those calling permission might include.  (If you want to talk to Mom in Italy, call my extension after hours and press zero when you here my greeting” is one of my personal favorites).

The video clip walks you through the process of creating a new User Group aptly named “Terminated Employee”.  This User Group then encompasses a body of restrictions that can be applied to a User, in this case a departing employee, with just a couple of key strokes.   The goal here is to nail down the employees call flow while you are working out the details of transitioning the employees work flow.    Clearly, you can just delete the user and be done with it, but normally business is not that simple.  Employees are part of Work Groups or  Hunt Groups that define a work flow and sometimes it takes a transition plan to get the details worked out.  In the mean time, we need to secure the phone!

QOS for ShoreTel VoIP Deployments!

Posted on by DrVoIP

Setting up QOS on your routers to support ShoreTel VoIP across a WAN connection requires that you employ some creativity in your configuration.   Think of Class Marking as a way of “coloring” packets so that the routers no how to treat the packets when there is any kind of congestion.   We want voice packets to have a priority over data packets, so we color them and tell the carrier or WAN router which color is voice.   Generally, QOS strategies employ the use of Differential Service Control Points or DSCP values.

These values are established by convention and can be generally summarize as IP Precedence Level 5 (101xx000 = DSCP bits) or DSCP Values of 160-184 to representing  “Express Forwarding” with a decimal value of 41.   The TOS byte in the IP header allocates the high order 6 bits to the DSCP value,  making Express Forwarding or EF equal to decimal 41 or 10111000 binary. Most carriers will comply with this class marking and will put IP packets marked with this value in the Low Latency or “go fast”  queue.  (See note below).

In the ShoreWare Director Portal you will find a link under Call Control to “options”.  On this page, you will find a box for DiffServ/ToS Byte (0-255).  This is where you will set your DSCP value, generally 184.   This will mark all voice packets originating from ShoreTel Voice Switches and IP phones.   A QOS configuration generally consists of three elements;  The Class Map, the Policy Map and the Service Map.  The Class Map tells us what it is we are looking for.   The Policy Map tells us what do when we find what we are looking for and the Service Map applies this information to the proper interface, generally the WAN side of your router.

Here is an example of a simple QOS configuration:

class-map match-any VoIP
match ip dscp ef

policy-map QoS
class VoIP
set ip dscp ef
priority percent 50

Basically, we are telling the router to look for incoming IP packets that have a DSCP value equal to Express Forwarding.   When we see these values we are going to know they are VoIP packets  and move them to our LLC where we have reserved 50% of the available bandwidth for use by the voice application.   It is important to note that queues in routers only take effect when we have contention for bandwidth.  The QOS statements help the router make decisions as to what queue gets serviced first.   Understand that, should queues fill up, the router will start “tail drop” and throw out packets no matter what the class mark!   This is a key issue, as the queue is for outbound processing.  What happens if some idiot is down loading Avatar from NetFlixs?  The incoming data flow could drown out any attempt to service outbound queue handling.

Lets look at modifiying our ShoreTel QOS strategy to provide for some additional configuration options.  One option is to set up an Access-List to capture information that might not be generated by a ShoreTel switch or IP phone.  ShoreTel uses a specific set of TCP/DUP ports that we can easily identify.  You also know the IP address of your ShoreTel server.  Why not set up an access list to look for traffic originating from the ShoreTel server or traffic originating or terminating on specific ports?  Here is an example, created by Brain Krail,  of a configuration that establishes the access list and also sets up several classes of service for voice, mission critical data and best efforts data:

access-list 197 remark “All SHoreTel”
access-list 197 permit ip any any dscp ef
access-list 197 permit udp any any eq 2427
access-list 197 permit udp any any eq 2727
access-list 197 permit udp any any eq 5004
access-list 197 permit udp any any range 5440 5446
access-list 197 permit udp any any eq 5060
access-list 197 permit tcp any any eq 5060
access-list 197 permit udp any any eq 111
!
access-list 198 remark Mission Critical
access-list 198 permit tcp any any eq ftp
access-list 198 permit tcp any any eq telnet
access-list 198 permit tcp any any eq smtp
access-list 198 permit tcp any any eq 3389
access-list 198 permit udp any any eq 3389
!
access-list 198 remark VPN Traffic
access-list 198 permit esp any any

class-map match-any VoIP
match access-group 197
match ip dscp ef

class-map match-any mission
match access-group 198
!
policy-map QoS
class VoIP
set ip dscp ef
priority percent 50

class mission
set ip dscp af41
bandwidth percent 30

class class-default
set ip dscp default
fair-queue
random-detect

int ser 0/1/0
max-reserved-bandwidth 100
service-policy output QoS
!
In this configuration we use our Class Map to look for packets that match our Access-List.  Clearly, we are scanning for matches and based on the match, we classify the traffic as voice or mission critical.  The Policy map then assigns the proper value or class marking based on the Class Map matches.   The Service-Policy at the end applies the Policy to the Serial Interface on this router, most likely going off to the Carrier.  Your previously co-ordinate  agreement with the carrier will result in them treating the packets as marketed an handling them accordingly.  We find that QOS configurations that use Access-Lists to further search out traffic and host IP addresses that generate voice media streams, do a much better job than those that rely solely on the DSCP mark setup in the ShoreTel Director.

Now about that ugly issue of the user downloading NetFlix! How do we tell the carrier not to exceed a certain about of traffic inbound to our router?  The following configuration is an example of “Policing” an inbound interface to throw away any traffic that exceeds the CIR rate we set up.   This configuration increases the likely hood that QOS will be effective outbond, by making sure the inbound bandwidth is not over subscribed by a user downloading over your voice traffic!

access-list 199 permit ip any any dscp default

class-map match-all test
match access-group 199

policy-map testPolice
class test
set ip dscp default
police cir 1000000
conform-action transmit
exceed-action drop

QOS is an essential part of any VoIP deployment.   ShoreTel Deployments  can benefit measurably by getting creative with your Configurations and thinking outside the simplicity of DSCP!    NOTE – you need to dig deep on circuits provided by carriers that are peering with another carrier to deliver a complete circuit solution.   We have experienced situations in which the carrier taking the order adhered to our QOS markings and acted according to plan.  However, when that carrier hands the packet off to another carrier for final delivery, you need to make sure that they are in fact, honoring the same QOS markings.    In one situation, though our carrier was handling DSCP as agreed, the carrier that they handed off the packet to for final delivery, did not use DSCP on the MPLS circuit in question.  Some carriers, by inter-carrier agreement, use the Experimental Bits to deal with QOS.  Be Careful as the techs you are working with may not even know this, swearing all the time that QOS is setup per DSCP value!

Give us a call if you want assistance on QOS setup for Voice and Video!

ShoreTel Database Replication and Manipulation of MAXDBQUERIES!

Posted on by DrVoIP

It really doesn’t matter what VoIP system you installed they all generally have one architectural characteristic in common; the configuration database.  Depending on the system, you might find a database engine that ranges in complexity from an Access Database to a full blown SQL database.  The database will store configuration information, status information and often, call detail records that document phone system activities.   The characteristic of the database that is consistent across all architectures is the fact that there can only be one “read/write” copy of that database!

Some phone systems distribute the database across multiple servers.  ShoreTel, for example, distributes components of the database to application servers and distributed voice mail servers that characterize the single image architecture in a multi-site environment.   We need to better how a change to the database effects the operation of the system, the bandwidth of the WAN links and the demand on the database engine.  First, what constitutes a change to the database?   Well clearly any configuration change that is made to the system.  For example, adding or deleting a User are clearly going to cause a database update!  Lets take a more subtle example, however. Lets consider what happens to a Agent in a Workgroup, located at a remote site, behind a distributed voice mail server.  Each change that Agent makes on their Call Manager represents a database change.   Logging into the system, and Logging out of the system are database changes.  How about, accepting a call being offered to the Agent by a Workgroup?

Each of these Changes is communicated to the database.  The change is first made on the “read/write” database and then replicated to the remote database copy.   ShoreTel system processes use MS Distributed Component Object Model (DCOM) objects to share information from the configuration database among themselves and to write configuration  information to the database.  User configuration options are written to the database from Personal Call Manager, and the telephone interface.  Each ShoreTel service on a distributed server caches it own copy of the configuration database.  When a distributed server loses connection to the HQ server (read “read/write” database) any changes made are no longer received by the distributed server.   If a DVM restarts without a connection the HQ database, services are started but are not functional.  When the network connection is restored, the configuration is retrieved and again cached by each service as the services become functional.

If there is a flap in the WAN we note that the DVM will in fact reload a copy of the database.  This movement of the database between the HQ server and the DVM servers clearly uses bandwidth and also makes additional demands on the database engine.   In ShoreTel the database engine, is now MySQL.   The question becomes how many simultaneous database access (read, modify, write) transactions can the MySQL server handle at one time?  What happens if the transaction can not be completed?  Does it queue and retry?   In a large system of say 700 workgroup agents at a site, is it possible to overload the MySQL database with state change requests?   If you dig down through the Server registry you will find the MAXDBQUERIES is set by default to 100.  It has been our experience that, defending on the size of the system, it is sometimes necessary to dial this number back to eliminate overloading the database.   This adjustment should be made only on the DVM’s in the configuration and not on the HQ server.   You will need to reboot your DVM servers after making this change.  You should also note the difference between HEX and Decimal!

The following SILENT file clip demonstrates how to make this adjustment.

ShoreTel Enhanced Workgroup Services!

Posted on by DrVoIP

Historically, there were three services in the ShoreTel architecture that were no distributed to other servers.   To oversimplify, this meant that if the HQ server (read primary server) was unavailable, the services that were not distributed would not function.  The three services were Route Points, Account Codes, and Workgroups.   For example, if a user group was set to “forced” account code verification and the server was unavailable, that service would fail and the affected user would not be able to place a call.   Likewise, if the HQ server were unavailable, Workgroup services would fail.  ( The “best practice’ deployment strategy was to backup a Workgroup with a “hunt group” given that the HG ran on a switch and not a server, it would continue to function in this scenario.  Calls targeting agents in a Workgroup would fail over to a hunt group that would target the same list of agents).

ShoreTel has steadily progressed the distribution of these services out from the HQ server to either SG switches or  Distributed servers.  With the latest release of ShoreTel,  they have migrated critical services to include Workgroup services.   This is a major enhancement and any organization that makes use of the Workgroup functionality, especially in a multi-site environment,  will realize a  benefit by these enhancements.

Through the ShoreTel administration portal, we now find a drop down window that enables us to select which server should be utilized to run the Workgroup we are defining.   For example, in a multi-site environment, I might want to have the Workgroups organized by Site and run the workgroup service on the DVM at that site.   This would keep the Workgroup local and a failure of the HQ server would not dramatically affect the workgroup at the remote site.   We note that, in the absence of the HQ server, we are still unable to make database changes.  For example, Logging In/Out of a Workgroup would not be possible, but the remote Workgroup would still function.

Additionally, we note that you can continue to name a Hunt Group as a backup extension.   The key difference here is that the Hunt Group can contain extensions that are Workgroups on other servers!   This offers a degree of flexibility not previously available and is a viable alternative to a straight Hunt Group solution.   A failure of the HQ server will only effect the Workgroups that are on that server and distributed Workgroups on other servers will continue to run.  A failure of a DVM with an operating Workgroup can fail to a Hunt Group that can be used to route calls to other Workgroups.

The vocabulary might be a bit confusing, but the strategy represents a significant step forward in assuring the operation of a distributed call processing application as powerful as ShoreTel Workgroups!

WorkgroupScreen