QOS for ShoreTel VoIP Deployments!

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!

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.