Voice communication via the Internet uses something called VoIP, or ‘Voice Over Internet Protocol’. VoIP uses ‘packets’ to send your voice from point A to point B, and vice versa. If you’re using a VOIP phone system for small business purposes, you’ll benefit from understanding how it works.
In the Internet world, when you talk to someone on the phone, your voice is compressed into data packets which are then sent via data path to their destination (which would be the person to whom you’re speaking).
The data path makes all the difference. The data path in question happens to be the Internet which, as you’re probably aware, is subject to a variety of complications.
Think of it this way: imagine you’re driving somewhere. You start at your home and you have a destination.
The quality of the road between here and there, as well as factors like the weather, dictate how long it takes you to get there. You may not get there at all. Suppose there’s a tree down across the road, and that road is the only route to your destination. You would probably turn around and drive home.
Data routes work the same way. If the data path is good (which, in the above example, would equate to clear roads and pleasant weather), then the data packets will have no problem reaching their destination. However, if the data path is poor (which would be stormy weather, trees across roads, flooding, etc) then it’s going to take the data packet longer to reach its destination, and it may not arrive at all.
Just because the data packet doesn’t arrive at its destination doesn’t mean that it’s gone for good. To go back to the driving example, if you have to return home due to poor weather, you don’t necessarily stay home forever. You might wait a couple of hours, or maybe until the next morning, to try to reach your destination again.
Data packets work the same way. If the data packet doesn’t arrive, then the destination will request that the data packet be re-sent using the Transport Control Protocol (TCP).
Here’s how timing works in regards to VoIP: by default, it takes a recipient about 40 milliseconds to receive a data packet. If the data path is clear and every data packet takes 40 milliseconds to transmit, then the conversation sounds perfect.
Unfortunately, the Internet isn’t always quite so predictable. Sometimes it can take the data packets longer to reach their destination. So one data packet might take 40 milliseconds, another might take 70 milliseconds, and yet another might take 135 milliseconds. As you can probably imagine, the 135 millisecond delay is noticeable – the packet is taking three times longer to reach the destination than is ideal.
Regardless of the amount of time it takes a packet to reach its destination, if the delays differ, it can create confusion between you and whoever is on the other end of the line. As you can imagine, delays in VOIP for small business can be a problem.
Sometimes, the packet doesn’t make it through at all, and it’s lost. The problem is that during a phone conversation, it’s virtually pointless to resend the data packet, because the conversation has likely already moved on. A lost data packet results in a “dead spot” in the conversation, which – in a business context – can be costly.
So there are two issues in the VoIP world: delay, and lost packets. Delay is when it takes packets longer to reach their destination than is ideal, and loss is when the packets fail to arrive at all. It’s important to note that you can experience these problems regardless of whether you’re sending packets over the Internet or via an internal network, as an internal network can get overloaded and result in lost/delayed packets.
One critical element for an internal network is the installation of a QoS-switch that will prioritize voice packets over data packets, meaning that the phone call packets will take priority above all else. This only partially solves the problem, however, because the data route is still the Internet, which is prone to vagaries.
Point-to-point bandwidth. It’s a pricey proposition – if you want perfect voice calling, then you’re going to have to pay money for it – and you’ll need the right infrastructure.
Voice packets tend to be sent on the User Datagram Protocol (UDP) rather than the TCP. TCP is “connection-oriented” meaning – as we covered before – that if a packet fails to arrive at its destination, it’s re-sent. With UDP, the packet sizes are smaller and unlike TCP, which requires receipt verification (meaning: TCP needs a receipt verification to ensure that the packet arrived at its destination. If it doesn’t receive this verification, it sends the packet again), UDP does not require receipt verification.
What does this mean for you as a user? It means smaller data packets, and it means that the packets won’t be retransmitted if they don’t arrive at their destination which, as we suggested above, is unnecessary anyway – by the time the packet is retransmitted, the conversation has moved on, making retransmission unnecessary.