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!

QOS for ShoreTel VoIP Deployments! is a post from: VOIP Tech Blog

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 Database Replication and Manipulation of MAXDBQUERIES! is a post from: VOIP Tech Blog

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.

ShoreTel Enterprise Contact Center Call Routing based on Schedules! is a post from: VOIP Tech Blog

What is that we need to monitor anyway? We split the monitoring world into two basic camps: Flow based accounting and Health checking software. Flow based monitoring enables us to check the source/destination IP address; source/destination port; IP protocol; TOS and Ingress interface. This is helpful when you are trying to figure out what applications are running on your network and who is streaming real time media. Clearly important stuff, but at the end of the day, when it comes to logging into someone’s network remotely and trying to figure out why some remote user has garbled phone calls, there is nothing like an in place Health check!

When we talk about the “health” of the network we are interested in knowing about Bandwidth capacity, Loss, Jitter, Mean Opinion Score (MOS), latency and tagging. These are the words that make a VoIP engineer smile! Would it not be wonderful to log into your clients network and have this kind of history available between key end points of a multi-site deployment? Rarely, do I ever publically endorse a product but the folks Apparent Networks have gone out of their way to make their product available, useable and free! You need to stop what you are doing and download Path View Cloud, a host based network monitoring solution from Apparent Networks.

Not only is this software as useful as a button hole, but you can download a fully functional 5 node solution for absolutely no money! In previous posts I have discussed the fact that, despite best practice, clients continue to attempt VoIP phone deployment over DSL through VPN tunnels! Path View Cloud enables you to collect real time network health information about key end points in your network. Typically, it is the remote user or the WAN points that you are going to want to study. Path View Cloud enables you to create monitoring solutions that regularly report on health checks and trigger alerts when “violations” have been detected. Yes, Virginia, there is a Santa Claus and you can see packets!

Clearly Apparent Networks believes that offering 5 free nodes will get you to order more! The offer is, however, compelling and I can tell all  you cheap, penny pinching, tight wads that will not invest in network monitoring software, that you will sleep better at night with this Path View Cloud solution in place. Network and VoIP engineers and technicians, you need this arrow in your quiver to make trouble shooting more visual!

VoIP QOS Network Monitoring and Pathview Cloud! is a post from: VOIP Tech Blog

Recently, we had to create an Automated Attendant on an Enterprise Contact Center. At first this seemed almost boring, but then we ran into an issue. You can use the MENU icon to create your Automated Attendant script, with a TRANFER icon to each destination selected by the caller. You can use the SCRIP icon to send the caller on to a script to collect information like the callers account number for a SQL database look up; but how do you send a caller to “service”? Now that was a more interesting challenge and I have to thank Chad Burnett for pointing out the use of what has become my favorite new ShoreTel ECC scripting icon: “the Change Profile” action. This icon is a powerful call profile manipulator and enables the Enterprise Contact Center configuration to explode with call processing options.

Using the Change Call Profile icon you can select various Call Profiles for manipulation. Each system contains a number of mandatory system level call profiles like ANI and Caller ID. You as a system designer can also create Call Profiles to meet the needs of your exacting design requirements. For example, you might add the Call Profile “Account Code” that you might use in a script that prompts the caller to enter digits that you will use to look up a record in a SQL database.

The Change Call Profile icon also allows you to select a previously defined SERVICE. The following video clip reviews how the iPBX and the ShoreTel ECC interconnect. It demonstrates the use of the Change Call Profile icon, by demonstrating the creation of a simple automated attendant!

ShoreTel Enterprise Contact Center “Change Call Profile” icon is a post from: VOIP Tech Blog

In the VoIP world in general and the ShoreTel world in particular, there is a measurable performance difference between an MPLS deployment and a VPN tunnel through the public internet.    An appropriately designed MPLS circuit with carrier Service Level Agreements in place will out perform the best VPN tunnel through the public internet.   Yet clients continue to believe they can put a VoIP handset  at the bosses house and run it over a DSL based VPN back to the “puzzle palace” and that it will  perform as well as the phone on his office desk.   The reality of the deployment is that this implementation seldom meets customer expectations.

A ShoreTel deployment of a remote handset for a home based work force can be accomplished under two basic models.   In the more desirable, albeit more costly model,  we create a “site” which involves the placement of a ShoreTel media gateway (read SG switch) at the remote location.  VoIP handsets interact with the SG media gateway or call manager at the remote location for all call setup, addressing, signaling and control.    In the ShoreTel world the call setup between a VoIP handset and an SG media gateway will use the MGCP protocol.   This protocol is a client/server or master/slave model and when compared with other protocols can generally be summarized as complex and “chatty”.   ShoreTel implements SIP for SG-SG communication, but uses MGCP for SG witch to handset call control.  Once a phone call is setup up, only the RTP media stream needs to traverse the VPN tunnel, however.

The other less expensive model s the placement of a remote VoIP handset only.   In this model, the handset is part of the “headquarters” site.  Unfortunately this is the deployment model we see the most when clients attempt to interconnect a single home worker with the corporate network with out the benefit of a carrier SLA.     A DSL, hopefully with a static IP address, and a device that can support a “point-to-point” VPN tunnel are the “minimum daily adult” requirement for VoIP connectivity.   In this model, the VoIP handset is communicating MGCP over the VPN tunnel with a call manager at the headquarters location.  Every handset action, from off-hook to digit key depress, is communicated over the VPN tunnel back to a media gateway at the home office.  Very “chatty”.

As engineers we can talk ourselves into a coma when discussing QOS options, DSCP markings, router queuing strategies and bandwidth reservation parameters.   At the end of the day, however, the only QOS “opinion” that really matters is what the users thinks!   Mean Opinion Score or MOS is the measure of what users rate the quality of a phone call.   Here is what we have learned after supporting hundreds of remote users on none SLA based circuits, typically VPN over DSL and Cable.   Rule one:  use only symetrical circuits (same up and down load speeds).  Rule two: Hard phones beat soft phones; and Rule three:  SIP phones beat MGCP phones.  It is that simple.   If we put a SIP based phone at a remote location, they will out perform an MGCP based handsets on the same circuit as measured by user MOS!  The SIP phone will perform with a higher level of reliability, be more resilient to latency and jitter, and will experience significantly less call disconnects than an MGCP based VoIP handset.

If you study the hosted VoIP service provider market, you will find that the predominant VoIP handset deployment strategy is SIP based.   Why is that?  We could go completely geek on you and  illustrate the complexity of call setup comparing MGCP with SIP setup messages, but why bother.  MOS rocks.  In this environment SIP deployments will yield higher customer satisfaction scores than MGCP deployments.   We are sincerely hoping and praying that ShoreTel has a “SIP firmware load” on the product road map to support their family of outstanding desktop handsets as they do not have a SIP handset solution.    Currently, when we have to support remote workers who insist on running VPN tunnels over DSL and Cable, we deploy Polycom and Aastra handsets to achieve maximum customer satisfaction in the wild west of internet telephony and home based workers!

SIP firmware for ShoreTel handsets? is a post from: VOIP Tech Blog

ShoreTel has always had a folder entitled “Shoreline data”, the name a residual of the company’s old name, look and feel. Historically, this folder contained all of the information you would need to have available to restore a crashed server from bare metal. The later releases of ShoreTel have moved configuration files to a MySQL database, but you still need to have this folder to do a system restore. The folder, among other items, contains the voice mail structure of your deployment and the actual voice mail files for each individual mailbox.

In the VMS folder, you will find two folders: “Message and ShoreTel”. The Message folder contains actual voice mail messages in ShoreTel WAV format; and the other folder contains a list of folders that match the number of each mailbox on the ShoreTel deployment. Each VM box folder contains a WAV file for the mailbox name and each greeting recorded in that users mailbox. The greetings have easy to recognize names like 115Greet01_01.wav which represents the Standard Call Handling mode Greeting. If you re-record your greeting you will create a new file named 115Greet01_X.wav, where X is the revision number of the recording.

There is a also a Mailbox.DAT file that contains system configuration information and the unique ID of every message received by that particular voice mail box. The actual voice message, however, is contained in a separate folder appropriately named messages! In this file you will find a unique message WAV file that is the actual voice mail recording. It will have the format 1K0VGJSGI.wav where 1K0VGJSGI being unique message identification. There will also me a matching 1K0VGJSGI.msg file that acts as an index pointed to by the unique message identification written to the DAT file in the individual voice mailbox folder.

ShoreTel has a number of debug and diagnostic tools that can be used to assist in administration and troubleshooting. The CFG.exe program is a useful tool for obtaining information about mailboxes, voice mail servers, phonebooks, automated attendant DNIS maps and other specific voice mail box configuration data. Using CFG you can turn on message waiting lamps, have the voice mail system dial specific extensions, list message details, purge and restore messages and generally manipulate the voice message structure. The three part video clip details all of this information for your education and enjoyment!

Fun with ShoreTel Voice Mail is a post from: VOIP Tech Blog

On PRI lines, we have more control over what is displayed when you place a call to an outside party. Generally, in ShoreTel you can display either the main PRI number of your personal DID number. We have been able to spoof the PRI D channel and display any phone number you may want on an outbound call, by configuration of the Caller ID field in the Shoreware Director administration portal under Individual Users.

We are often asked if it is possible to display a different outbound caller ID on a call per call basis. Unfortunately, unless you are willing to reconfigure the Caller ID field this is difficult, but not impossible to do. ( I know at least one police department and a half dozen credit and collection agencies that do this when the called on suspects might not answer the phone unless they know that Mom is calling)! Sometimes a company has multiple Brand names or company names that they are using when they place phone calls. To enable call by call, outbound CID change, we create Bridged Line Appearances or BLA’s. These BLA’s can be configured with a different called ID and the client can select the appropriate line (read Brand) to generate the correct CID on a particular outbound call. As an aside, we note that the carriers are getting more particular about D channel spoofing of CID on PRI calls. On SIP trunks it is all but impossible. The Carriers now insist that the displayed number must be a number that is within your BTN range. This limits spoofing.

Trouble shooting inbound (or outbound, for that matter) Caller ID calls on a ShoreTel PRI is fairly straight forward. Minimally, you can use the Trunk Test tool to witness the caller ID of an inbound call. To tap the actual D channel messages sent by the carrier to your ShoreTel SGT1, you will need to setup a capture. To do this, you will need to take the following steps (see video below):

(a) Turn off the Telnet Security Shell via the ipbxctl command

(b) Telenet into the ShoreTel SGT1 switch;

(c) For Analog & T1 turn on the mpm_debug_mask=-1 command

(d) For PRI use mpm_debug_mask=0X40 for called ID and Name.

Unlike the early versions of ShoreTel debug routines, the CID and call setup information is reasonably intuitive to decipher. Traces can also be used to figure out who hung up on who and other carrier CPE shoot out questions. These are useful trouble shooting tools.

Lastly, we need to make sure we understand the difference between ANI (automatic number identification) and Caller ID. ANIS is tariff differently and is not subject to the same blocking restrictions as caller ID number. Generally, if you are paying for “toll free” numbers, you want to know who is calling! The carrier delivers the information in a format that looks like <DID> <DNIS> * <ANI> * <DID/DNIS> and the SGT1 can note the *delimiter and sort this out. You should also be aware that ShoreTel will attempt to route the call based on a selection priority that starts with DNIS, DID, Extension and finally Tandem Trouncing. If no match is found, the inbound call will be routed to the “destinations” specified for the trunk group, with the automated attendant being the default.

Trouble Shooting ShoreTel SGT1 Caller ID is a post from: VOIP Tech Blog

Playing with route points is an interesting experience as they seem to work differently depending on which version of ShoreTel you are running.   In all versions, however you can create a route point and associate it with a voice mail box, or use it to deflect a call.   Historically, we have used route points, along with schedules, to redirect call center traffic between different call centers based on the time of day or day of week.

It is quite possible, however to set up a route point for no other purpose than to create a fully functional voice mailbox.  Given that the route point does not require the definition of a user, no extension or mailbox license is required to achieve this result.   Basically, you create an route point much the way you would create a Hunt Group, Automated Attendant or Workgroup.   You define the route point with an extension that can be dialed, and you setup your Ring No Answer and Busy Destinations to be the voice mail port.

We have come to realize that you have to use the Record function on the Route Point configuration page to set the recorded name and greeting. Thought we could enter the same VM box through an IP phone and were greeted with the normal new voice mail box setup routine, when we called the box we did not hear the name or greeting. Using the record option on the configuration page, however, enabled this functionality. After recording the greeting and name in the way, we experienced the expected behavior when we called the extension and were transferred to VM.

Route points can also be used to deflect an incoming telephone call to an external telephone number. This is equivalent to setting your call handling mode to always call forward to an external number. We never encourage users to configure this option in their call manager, as it robs the host company of follow on call control, allowing messages to be taken by a cell phone for example. The fact remains, however, that you can setup a route point, with a DNIS or DID number to always send the call to a remote phone in the pubic switched telephone network.

Route points that forward to traditional TDM connections will actually show up in the ShoreTel CDR when you run a User Detail or Summary Report. This is not the case if you try to run these reports against a route point that is actually used as designed and terminates in a third party call control application via TAPI. This is just one of the mysteries of route points. At the end of the day you could setup a ShoreTel server with no users or extensions, using route points to enable both voice mail and remote call forwarding. Route points are just way kool and worthy play things! More on this later, film at 11.

ShoreTel Route Point Configuration is a post from: VOIP Tech Blog

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

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

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

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

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

To VLAN or not to VLAN, that is the question! is a post from: VOIP Tech Blog