IP Telephony features are not always “plug-and-play.” Rather, they must be configured to function properly. This is equally true when dealing with quality of service (QoS) on a network that transmits both data and voice (i.e., a converged network).

Companies commonly find that when they install their VoIP system on a preexisting data network, it works great at first. Days or weeks later, however, users complain of poor voice quality and intermittent disconnections. The network has not changed, so what’s going on?

In this article, we’ll see why QoS is a fundamental part of your network design for voice, and examine five configurations that should always be employed to achieve high-quality voice on a converged network.

Why does voice sometimes sound bad over a data network?

If you deploy a VoIP system, all you need to do is plug the phones in to the existing network switches, configure the IP PBX and everything should work, right? Well, the answer is an emphatic “it depends.” QoS may be employed at the IP phones, at the IP PBX, and at the voice gateway, but if the intermediary network devices such as routers and switches are not configured to react to the QoS markings and appropriately prioritize packets, then the QoS configuration will be insufficient.

Remember that problems arise for voice packets only when there is network congestion. Network congestion occurs when the rate of the arrival of packets over a particular link within the network exceeds the capacity of that link. So, if you have two switches connected via a Gigabit Ethernet link, and you have packets attempting to traverse the link at any rate above 1 Gigabit/second for any period of time, you will encounter congestion.

The congestion experienced by voice packets that can potentially cause poor voice quality is due to other forms of data using the network, not the voice traffic itself. Voice comprises a tiny part of the bandwidth: typical required speeds for voice range from only 8 to 80 kbps, and sometimes a little bit more, depending on the codec being used. This means that a single Gigabit Ethernet link can carry in excess of twelve thousand simultaneous voice conversations, well beyond what most enterprises require for their whole networks!

While VoIP packets will never be the cause of network congestion, they will suffer because of it. So QoS is essentially required to make sure that the small trickle of voice packets through the network remains steady, even in the event of a large file transfer or network backup attempting to commandeer the same link.

I’ve got a fast network; why employ QoS?

A somewhat misguided approach to the problem of network congestion for IP telephony is to overprovision. The thinking goes, if you make the link bandwidths large enough, then, theoretically, you should never have congestion and you should not need to employ QoS. Although this seems logical, it is a costly and ultimately impractical way of approaching the problem.

Network congestion is a dynamic occurrence and, although it can be directly affected by the creation of bottlenecks due to poor network design, it largely depends on multiple and unpredictable factors, no matter how much you overprovision. These factors can include dynamic traffic patterns of users, the addition of new network applications, the creation and execution of network server backups, or the misconfiguration or malfunction of Layer 2 loop-prevention mechanisms such as Spanning Tree Protocol (STP) or of Layer 3 routing protocols, to name a few.

Even if your data network provides gigantic pipes for data to flow through, there is always the possibility of network congestion. For this reason, QoS should always be employed from end to end on all devices that will be carrying voice packets regardless of how “fast” your network may be.

How do I apply QoS to the LAN?

In a previous article, we talked about the two major approaches to QoS: IntServ and DiffServ. We will focus on DiffServe here, since it is more common and relevant for use within LANs.

Devices that are sources of voice packets on a network include both IP telephones and voice gateways. Before sending voice packets to their intended destinations, these devices mark them using Differentiated Services Code Point (DSCP) values in the IP header. To make sure these markings are taken into account by your network and are not ignored, implement these five practices:

1. Verify that the network design minimizes bottlenecks – First and foremost, the network should be designed with sufficient bandwidth at the core, distribution and access layers for the expected network traffic. QoS is only necessary whenever congestion occurs, and if you minimize congestion with an appropriate network design, then most of the potential problems facing voice packets will be avoided. Remember that DiffServ is sufficient to deal with any congestion that may take place on a properly configured LAN. In the event of an enormous amount of congestion, DiffServ will eventually break down, but such congestion should never be experienced on a properly designed LAN.
   
   
2. Configure QoS on all routers – Make sure that all of your routers carrying voice traffic are configured to give the proper priority to marked packets. If this is not done, then any QoS markings that VoIP end devices employ will be for naught. When congestion does occur, no priority treatment will be employed by the network. It’s like sending a letter by first-class mail, only to have the postal workers ignore the sticker on the envelope and send it by bulk. If congestion occurs at even one improperly configured router in the path of the voice conversation, it could be enough to disrupt your voice traffic flow.
   
   
3. Configure QoS on all switches – Because DSCP values are only relevant at Layer 3 of the OSI model, Layer 2 devices such as switches are unable to read them. It is vital that all switches that carry voice packets be configured so their trunks operate using the Class of Service (CoS) markings found in the header of the Ethernet frames traversing them. The appropriate DSCP-to-CoS mappings should be in place so that switches maintain the same degree of priority for voice packets as the routers do.
   
   
4. Configure VoIP devices to apply QoS to control traffic – VoIP communication is comprised of two types of packets: control packets, which use the Session Initiation Protocol (SIP), and the voice packets themselves (for more details on this, see our article on what’s so special about SIP). Not only is it vital that voice packets be prioritized using QoS mechanisms, but the SIP control packets should be marked for QoS, as well. This will solve problems like a “delayed reaction” of a phone when it goes off hook, when transferring calls or when various tones are played in the earpiece.
   
   
5. Take advantage of en-route DSCP modification – Routers are capable of modifying the DSCP values of packets they receive and route to their destinations. This is especially useful when you have other types of high-priority data on your network, such as video on demand, IPTV, or security system data that may be set to higher values than your voice packets by the participating end devices. Sometimes you can’t change the QoS settings on these devices, either because they belong to private users or simply because they are not configurable. You can, however, configure your routers to modify the DSCP values of particular packets en route, thus realigning their priority to what best suits your network.

Conclusion

Quality of service is an often-neglected part of voice network design. Many manufacturers assert that their voice endpoints already employ QoS, and rightly so. But this can mislead network administrators into thinking that no additional QoS fine tuning is necessary for voice to function on their networks. With the appropriate checks, configurations and network adjustments, you can verify that your network is ready to appropriately prioritize voice packets in the event of network congestion.

You may also like:

Using Wireshark to troubleshoot VoIP

Implementing VoIP safely and efficiently on the network edge

Worker overwhelm and the demand for UC