Add a Comment Now - We Want to Hear From You
Anytime you add a new application to the network, unexpected results (if not outright chaos on the order of the fall of the tower of Babel) often ensue. VoIP is no different and can affect network performance particularly. This is why efficient VoIP management is so important.
Most traditional networked application performance – email, ERP, Web, and database applications, have a few key assumptions. They usually use the TCP protocol, which is reliable and sacrifices time for accuracy, changing for new network conditions. They can usually tolerate packet loss (because of the TCP protocol’s ability to recover) and delay (because there’s no need for real-time throughput.) Applications slow down, but are still usable.
They also typically have a client-server structure, and transactions are made of requests and responses. From that point, you can look at traditional apps with traditional metrics – response time, network round-trip time, network connection time, retransmission delay, and throughput.
Underlying these high-level application metrics are the basic network performance metrics of packet loss and latency. If your network has high packet loss, applications will have to retransmit data, thus affecting performance and adding delay. Under conditions of high latency, applications that use many transactions are the most severely impacted. 100 ms of latency may not sound like much; however, couple that with hundreds of back-and-forth transactions and it can add up to many seconds of delay.
All of these are useful for transferring, say, an e-mail message or a file. If an email message is delayed by a few seconds, it is likely that no one will notice. However, if part of your voice conversation is delayed by a few seconds, you may hang up the phone. VoIP traffic has different performance requirements.
VoIP applications use the RTP protocol instead of another protocol such as TCP because they must send data immediately and cannot wait for retransmissions. If an RTP packet is lost, it’s lost, and there’s no chance to retransmit it. And if a group of consecutive packets is lost, entire portions of the conversation can be wiped out.
Additionally, VoIP applications send small data packets. If a single packet is lost, it means less data is lost with it. But more importantly, codecs usually send packets out every 20 milliseconds – to keep up with the real-time demand of the conversation.
Without proper quality of service mechanisms on the network and a VoIP management plan in place, these small VoIP packets can get blocked behind a larger data packet waiting to be sent on a slower-speed WAN link.
VoIP applications also have strict delay requirements – anything over 150 milliseconds of delay turns a “phone conversation” into playing with walkie talkies. This delay can be caused by a number of factors – Packetization delay is the time it takes to turn a voice into data and data into packets, network delay includes the time to transmit, buffer, and queue the packets from hop to hop through the network, and jitter buffer is added by the receiver which buffers packets in order to reduce the impact of variations in packet arrival times – so that the phone conversation doesn’t sound “jittery.”
Additionally, a good VoIP management stategy requires QoS for the VoIP applications. With an “ordinary” phone call through a PSTN, the resources needed for maintaining a call is guaranteed throughout the call. But IP networks do not operate this way – in an IP network, the resources are shared by many different users, and congestion at the router can impair VoIP call quality. Because of this, a QoS scheme that provides prioritization for VoIP traffic management is required for every VoIP deployment.
We’ll discuss the underlying network metrics that affect VoIP call quality in Part 2 of this post.
----------------------------
More information on:
