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. Email is occasionally described as a "store and forward" protocol, and even though it is not absolutely correct to classify it this way (refer to the Wikipedia definition), it does render the idea that 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, and in the vast majority of cases, nobody really cares about the delay - particularly keeping in mind that a person's mailbox can receive several messages in a very short span of time, making it 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 nil.
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, and will severely impact the perceived call quality.
Assuming that your internet and networking services have sufficient bandwidth generally to carry your voice traffic, it is fairly safe to conclude that whenever you encounter call quality issues of this type, the cause is due to some point of the network being sufficiently overworked, 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. If, for example, you reserve 100kbps, of the 2000kbps bandwidth available, for VoIP traffic, then even 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, and 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, and 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, with the behaviour typically being one of 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, and at the end of this chapter you have a simple 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). This is 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 (typically by making an extension to extension call where both extensions are on the same LAN as your PBX) does NOT experience call quality issues.
If the answer to both questions is "yes", then it is fairly 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, allowing you to daisy-chain a PC to the LAN through the phone, reducing 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.
- Some calls have call quality issues throughout.
- Some calls start off ok, with call quality degrading at some point during the call.
- Some calls start 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 - a graphics design house, for example.
If your LAN is composed of two or more sites linked together over an MPLS network, these symptoms can manifest themselves 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 your IP-PBX) and 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 wish to refer to Donald Egbenyon's Bachelor Thesis, Turku University of Applied Sciences:
https://www.theseus.fi/bitstream/handle/10024/38426/bachelor_donald.pdf
WiFi Networks
If you are using WiFi devices inside your premises, do keep in mind that each Access Point has a limited coverage area, and that 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 typically achieved by using multiple Access Points that present the WiFi device with a single WiFi zone, while the back end takes care of managing which Access Point will provide the service.
A Word About VLANs
For most network engineers, the preferred sure-fire way to handle potential issues of competition for bandwidth between Voice and Data 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 most certainly a very effective way of approaching the challenge, you must keep in mind that the concept of Unified Communications is to bring about a convergence of Voice and Data. In particular, a user who runs a VoIP application on his desktop computer (a 3CX client being an excellent example) 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
Phone System 
