Author: DrVoIP

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

ShoreTel CDR Format- How to find the International Calls!

Posted on by DrVoIP

Recently, while working with a third party Call Accounting vendor, we had an opportunity to revisit ShoreTel CDR records.  ShoreTel stores CDR records in two locations for two different purposes.  Historically, the first format is basically the “Legacy CDR Text Files” and they are stored in the Shoreline Data folder as log files.  The log files are written to \Shoreline Data\Call Records 2 and are written out at Midnight to a file named CDR-YYMMDD.HHMMSS.log.   This is the file that is generally accessed by third party Call Accounting software vendors.

The second format is written to a MySQL database which is used to generate call accounting reports directly from the ShoreTel server.  In version 7 ShoreTel began to migrate away from Microsoft Access to MySQL for both the CDR and the configuration database.   There is a procedure for converting the older files into the new MySQL format, but we are not going to cover that as most people have already made this transition.      The MySQL database also opens the opportunity to create custom reports using SQL queries.  Through the ShorewareDirector portal, under Reporting options, you can set the Retention Period for CDR Data as well as the Archive retention period.

CDR Options in ShorewareDirector Portal

If your third party Call Accounting software uses the 011 to detect an international CDR record, you will need to make some adjustments.  ShoreTel uses a Canonical format to collect digits.  This means that no matter what the user actually dials on the phones keypad, the system internally converts the numbers to +country-code area-code subscriber –number.   The fact that you dialed 9+011+52+3654587 will be stored in the ShoreTel CDR log file as 9+523654587 and the 011 reference will not be in the record.  The following silent film clip walks you through the format and content of the CDR.log files.

Configure ShoreTel for Redundancy, Resiliency or Business Continuity?

Posted on by DrVoIP

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

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

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

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

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

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

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

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

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

DisasterRecovery

Why move the Auto Attendant into the Contact Center?

Posted on by DrVoIP

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

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

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

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

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

Mobile Call Manager for the iPhone?

Posted on by DrVoIP

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

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

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

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

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

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

Find Me Locations
Find Me Locations

Call Handling Modes
Call Handling Modes

Select your Desktop or Iphone as prmary answering point!
Select your Desktop or Iphone as prmary answering point!

ShoreTel Enterprise Contact Center Call Routing based on Schedules!

Posted on by DrVoIP

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

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

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

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

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