A quick definition of the term “Real-Time” is in order here. Probably the best way to explain this is by subtraction, or by explaining what it is not. Consider the timings behind the process of sending and receiving an email message. There is commonly a measurable delay between the composition plus sending of an email, and the eventual reception and reading of that same email.
This delay between sending and receiving is largely irrelevant for email delivery. In the vast majority of cases, nobody really cares about the delay. Especially when a person’s mailbox can receive several messages in a very short span of time. It is impossible for the reader to process the contents immediately.
In summary, if an email is delayed by a few minutes, the impact on operations is virtually none.
Voice communications, on the other hand, are of a completely different nature. During the course of a phone call, a propagation delay of more than around 400 milliseconds is immediately noticeable to the participants. This will severely impact the perceived call quality.
Assuming that your internet and networking services have sufficient bandwidth generally to carry your voice traffic, whenever you encounter call quality issues of this type, the cause is due to some point of the network being sufficiently overwork or congested. This introduces additional delay beyond the normal propagation delay (which most people call “ping time”).
What is QoS?
Quality of Service, in the context of VoIP, is a collection of concepts and techniques that come together to provide a means to safeguard optimum call quality within the constraints of the limited bandwidth available.
Bandwidth Reservation
This mechanism, sometimes found on entry-level routers, simply reserves a certain percentage of the available bandwidth for classified traffic. For example, if you reserve 100kbps, of the 2000kbps bandwidth available, for VoIP traffic. During times when other traffic is competing for bandwidth, the router will guarantee bandwidth for VoIP; if the VoIP traffic requests 50kbps, then the router will fully satisfy all VoIP traffic requests, the remaining bandwidth will be utilised for other traffic. If the VoIP traffic requests 300kbps, then the router will guarantee 100kbps for VoIP, while the remaining traffic competes for the remaining bandwidth.
Traffic Tagging
Network traffic can be tagged with special markers to indicate priority levels. The mechanism is documented in RFC 2474. It defines the “Differentiated Services” field in IPv4 and IPv6 headers for traffic classification purposes. Note that this mechanism is simply a way to mark packetS. So any routers or hops involved in the flow of traffic may implement specific behavior relevant to the class of traffic. The behaviour typically is one of the prioritizing the traffic based on class. If you need to implement QoS, your task will involve configuring your VoIP devices. Particularly your 3CX machine, to tag VoIP traffic appropriately for routing devices to action accordingly. On Windows-based Operating Systems, this is implemented at Local Policy or Group Policy level. At the end of this chapter, there is an example to implement QoS tagging on Windows 2008 or 2012 Server.
Prioritization
Tagging traffic is only a part of the solution. You will also need to make sure that all intervening devices and services prioritize the tagged traffic. In particular, you should ensure that your Internet Service Provider does honour tagged traffic, and that it will prioritize accordingly.
Typical Congestion Points
To better understand how to address network congestion, some pointers on “where to look” can come in very handy. What follows is not a completely exhaustive list, but certainly a great starting point.
WAN-to-LAN device (Router/Firewall)
Even though internet connectivity continues to improve practically everywhere, the available bandwidth remains a limited resource.
Your first sanity check should always be to ensure that you are not attempting to deliver more calls across your internet connection than your bandwidth can handle. Most internet connections are asymmetrical – meaning that the download and upload bandwidth availability is NOT the same. Typically, upload bandwidth is significantly lower than download bandwidth, and therefore it is generally the upload bandwidth that is your limiting factor (bottleneck). Because a voice conversation requires voice data to be sent and received simultaneously.
One simple way to try to confirm that the congestion point is at the WAN-to-LAN device is to check that:
- A voice call that travels over your internet connection experiences call quality issues.
- A voice call that does NOT travel over your internet connection does NOT experience call quality issues.
If the answer to both questions is “yes”, then it is sure that the congestion point is your WAN-to-LAN device.
Desk Phones used as Mini-Switches
Many SIP desk phones today offer the added convenience of a second ethernet port. This allows you to daisy-chain a PC to the LAN through the phone. It will reduce the number of network points that you need to deploy into your premises.
Certain situations, however, can give rise to seemingly unexplained call quality issues. These symptoms are typically intermittent, experienced only by one user at any point in time, with no real difference between whether the call is to another LAN extension or to an external caller.
- Most calls seem fine.
- Having call quality issues throughout.
- Started off ok, with call quality degrading at some point during the call.
- Started with bad call quality, with the problem disappearing during the call.
This can sometimes be traced to the fact that the PC connected to the Desk phone in question is making sufficient use of the network to overwhelm the processing power of the phone. You can confirm this by disconnecting the PC from the phone.
Internal LAN Devices
Certain network layouts can also occasionally expose symptoms very similar to the ones described above with a PC connected to a Desk phone. This time however, the incident is very likely to be related to intermittent very high network usage. More susceptible than others would be environments requiring transmission of very large documents over the network. For instance, a graphics design house.
If your LAN is composed of two or more sites linked together over an MPLS network, these symptoms will occur more than over a conventional LAN.
Arguably, the best way to address this type of scenario is to implement QoS on the LAN. By implementing traffic tagging on VoIP devices (including IP-PBX); by ensuring that your switches and routers are correctly configured to prioritize traffic based on the traffic tags.
For some interesting reading on this topic, you may refer to Donald Egbenyon’s Bachelor Thesis, Turku University of Applied Sciences:
https://publications.theseus.fi/bitstream/handle/10024/38426/bachelor_donald.pdf
WiFi Networks
If you are using WiFi devices inside your premises, do remember that each Access Point has a limited coverage area. A WiFi device that moves from one Access Point to another will need some time to “roam” across. This can take long enough to drop a call and require your WiFi device to re-register itself with 3CX .
You may need to investigate a WiFi infrastructure that reduces the handoff process to no more than milliseconds to avoid such situations. This is achieved by using multiple Access Points that present the WiFi device with a single WiFi zone. The back end takes care of managing which Access Point will provide the service.
A Word About VLANs
For most network engineers, there is a preferred way to handle potential issues of competition for bandwidth between Voice and Data. It is to keep the different traffic types separate. By segregating Voice into its own LAN using a physically separate network of switches, or using VLANs to achieve the same scope.
While this is a very effective way of approaching the challenge, the concept of Unified Communications is to bring a convergence of Voice and Data. In particular, a user who runs a VoIP application on his desktop computer, immediately brings about the need for Voice and Data to travel on the same LAN – and the trend is certainly making this the “normal” way to work.
You may find that QoS on the LAN brings about better returns when addressing such issues.
See Also
Configuring QoS on Windows