Deploying voice over internet protocol (VoIP) means much more than just exchanging traditional phones. It includes capital investment decisions, switches that support Power over Ethernet, VLANs and QoS, special power supplies for the switches, bigger air-conditioning and possibly bigger racks and closets, as well as the actual phone equipment.
Typically an investment runs at somewhere around e500 per user. Larger companies can gain economies of scale. The operating cost of VoIP is around e500-900 per user per annum.
VoIP is not as stable as legacy phone systems and the same sound quality is hard to achieve, if not impossible. Further, availability of traditional systems is extremely high. In fact these are one of the few applications or systems to reach the fabled 'five 9s' (99.999 per cent) availability.
In order to offer and maintain a similarly good service you need to manage your VoIP system efficiently, enabling you to respond quickly to quality or availability issues. Monitoring and troubleshooting equipment must be in place. Entry level for mid-sized companies would start from around e50,000 for management tools, the investment increasing with size and the number of staff needing training.
The network infrastructure needs to be verified. A network assessment is required to verify that the network can handle the amount of additional traffic as well as the traffic type. There are a number of packages that can simulate a complete VoIP system.
They allow you to 'see and feel' how the VoIP application behaves on your network, including the performance of a WAN environment. In addition real simulations may not be possible on operating networks due to the negative impact on existing users.
In this case it is necessary to have monitoring equipment deployed, allowing you to predict future traffic volumes based on the current performance.
When planning or troubleshooting it is critical to understand the three 'enemies' of call quality:
- delay;
- packet loss;
- echo.
- Delay
A generally accepted level for delay is 100ms. Above that number, most people will start to complain about the quality of the call. There are several sources of delay between the two phones.
Telephone / codec delay
The first is the telephone itself. The process of converting the analogue signal to digital and compressing it takes time. The amount of time is dependent on the compression algorithm (or codec) used. Algorithms that achieve higher compression and therefore require less bandwidth also take longer. The most common codecs are described in the table below.
Propagation delay
The second source of delay is the 'physical' time it takes for an electrical signal to travel from point A to point B. Since this happens at almost the speed of light, 3ms of delay per 1,000 kilometres will be added to the overall delay. If you have a phone call from London to New York, roughly 20ms of delay will be added purely due to the propagation time.
Jitter
Dealing with jitter results in the third source of delay. Jitter is the delay variation between packets when a packet travels across a network. There are many sources of jitter (router queuing for example) and therefore there needs to be a mechanism in place to eliminate the variation in delay between packets.
This is what the jitter buffer is for. It will buffer incoming packets and send them out in the original time relationship as they were put on to the wire. This is only possible because the packets carry a timestamp within the frame. Modern jitter buffers are dynamic and will only buffer packets for as long as needed and send them out immediately after eliminating the existing jitter.
Static jitter buffers on the other hand keep traffic in the buffer for the time it has been set for. The actual size of the buffer will be the amount of time that is being added to the overall delay. So if the jitter is 40ms (which is low), 40ms of delay will be added through the jitter buffer.
WAN delay
WAN delay is the unknown in the delay calculation - it is what we have been saving our delay budget for. The source of this delay is the WAN devices (typically routers) between the two endpoints.
Most of this delay results not from the routers themselves but from the queuing that takes place as links between busy routers. If there is an average utilization of more than 40 per cent on the WAN link, there is a high chance that the delay will become problematic. Even if QoS is enabled, delay will be added as the router still has to make a decision based on packet content prioritization.
If the buffer overflows the router will start to drop packets, end devices will retransmit and additional traffic will be added to the WAN, increasing delay further. The total amount of WAN delay is therefore dependent on the number of routers between the endpoints and the utilization on the links between them.
Now you can think about where you would like to deploy VoIP and make your own calculations. In our typical example we would have a maximum of 30ms of budget left for the WAN delay before call quality would suffer noticeably.
If you have a service level agreement with a provider regarding latency for any given application, think about how high that is... and if it would be enough for your VoIP application.
Once the delay budget is handled there are still two enemies to consider.
Packet loss
Packet loss is mostly due to overloaded WAN interfaces where there is a reduction in bandwidth from a local LAN to a wide area network. The source for discards is the end device itself. Due to various reasons it may discard packets. Phones are designed to handle some packet loss, typically replaying the last packet in place of the lost one.
The listener will usually not notice because the human brain will compensate. However this will not be the case if you have bursts of lost packets. Packet loss is acceptable up to 5 per cent but not in bursts.
Echo
The last parameter is echo. Every telephone system has an echo but as the round trip delay is typically 50ms or less, the echo is cancelled out by the talker's own voice. If there is a round trip delay of 200ms or more the echo becomes audible.
The industry has reacted to this and has started to build an echo compensation mechanism in the hardware that transforms analogue into digital signals and vice versa. If such a mechanism is not in place echo can almost be worse than delay.
Echo is part of the data in the frame and therefore cannot be measured; therefore it is very important that your test equipment is capable of replaying the voice.
Conclusion
The conclusion is that you should tune your network to become voice ready. A certification would for example include a simulation of voice traffic, WAN traffic measurements, quality measurements and QoS testing during those simulations.
You should also ensure that your network (especially at the core) has sufficient available access points in case you need to troubleshoot any problems. This is particularly true in the case of a distributed environment with offsite VoIP installations on the edge of the network.
You must ensure that you are able to locate the access layer switches and have spare ports for analysis tools to link up to the network and run packet captures. Lastly ensure you have enough trained resources available that can install, maintain and troubleshoot this new technology.
