VoIP Bandwidth Requirements
Tuesday, October 16th, 2007If you're new here, you may want to subscribe to our RSS feed. So that you can read the latest updates about VoIP Technology, Providers, VoIP Hardware, our Reviews or Price Comparisons for You to save and many more. Thanks for visiting The New VoIP Magazine!
VoIP creates two types of network traffic – the call control messages used to setup and manage connections between users, and the digitally encoded voice conversations. The call setup and management protocols involve simple messaging between IP phones and an IP PBX. These protocols use very little bandwidth and they do not have stringent latency requirements. A delay of a few seconds in setting up a call is usually acceptable. The real challenge is to satisfy the bandwidth demands of the digitized voice streams between users. Each call consumes a nearly constant amount of bandwidth for the duration of the call. How much bandwidth is needed for each call? That depends primarily on the voice encoding technique used as well as a couple of other variables. Two voice encoding standards are widely supported by VoIP products. The first is the G.711 standard that uses the same PCM encoding used on the PSTN at a bit rate of 64 kbps. In contrast to the PSTN approach of sending 8-bit PCM voice samples at 125 microseconds Page 2 intervals, G.711 packs multiple samples into each IP packet sent. Packing multiple PCM voice samples into a single IP packet reduces packet header overhead. Each VoIP packet is made up of IP/UDP/RTP headers in addition to the voice sample payload. Because these headers total 40 bytes per packet it is important to minimize the total number of packets sent. The maximum payload sizes are limited by the encoding latency as payload size is increased. G.711 payloads are usually limited to 160 bytes (20 ms. of voice) or 240 bytes (30 ms. of voice) because larger payloads would increase the encoding latency beyond acceptable limits and cause perceptible delays in conversations. G.729 is another widely supported voice encoding standard. G.729 encodes voice at a bit rate of 8 kbps by compressing as well as digitizing the voice signals. This compression is lossy and can degrade voice quality compared to G.711 encoding. The payloads of G.729 packets are typically 20 or 40 bytes. Although G.711 and G.720 encode voice at bit rates of 64 kbps and 8 kbps respectively, the actually link bandwidth consumed is greater because of the IP/UDP/RTP packet header overhead. The actual link bandwidth requirements for G.711 and G729 are: G.711 with 160 byte payloads 83 kbps G.711 with 240 byte payloads 76 kbps G.729 with 20 byte payloads 26.4 kbps G.729 with 40 byte payloads 17.2 kbps Link bandwidth requirements can be reduced for all encoding schemes by using a technique called RTP Header Compression (cRTP). cRTP operates hop-by-hop and compresses the 40 byte IP/UDP/RTP headers to 2 or 4 bytes. Link bandwidth requirements when using cRTP are: G.711 with 160 byte payloads 68 kbps G.711 with 240 byte payloads 66 kbps G.729 with 20 byte payloads 11.2 kbps G.729 with 40 byte payloads 9.6 kbps Another technique, called Voice Activity Detection (VAD) can further reduce link bandwidth requirements by detecting periods of silence in conversations and preventing packets of silence from being sent. VAD works with all encoding standards and can typically reduce the per call traffic volume by about one third, but its statistical nature means that actual link bandwidth requirements are reduced only in situations where a large number of VoIP calls share a link. VoIP Performance Requirements VoIP has three specific performance requirements that have to be met in order to provide toll quality voice conversations. The first is end-to-end latency. Anyone who has ever tried to carry on a conversation over a satellite link knows how excessive latency impacts quality. Long delays make it difficult for callers to determine when the person at the other end has finished talking. This results in very unnatural speech patterns. How much latency is too much? A rule of thumb is that one-way latency should not exceed 150 milliseconds. 150 millisecond delays are noticeable, but when latency exceeds 250 milliseconds it becomes difficult to carry on a conversation. Latency is a non-issue on the PSTN, but delays on IP networks can easily cause latency to exceed 150 milliseconds.
End-to-end latency is the sum of encoding/decoding latency and transmission latency. The level of compression provided by the codec is proportional to the encoding/decoding latency it introduces. For example, G.711 performs no compression and adds negligible latency while G.729 codecs compress voice to 8 kbps but add a one-way delay of about 25 ms. More significant delays can occur when voice packets are transmitted across a network, particularly when low speed WAN links are involved. The following chart shows the latency that results when voice packets get “stuck” behind data packets of different sizes being sent over WAN links. On T1/E1 and faster links this latency is only a small fraction of the total one-way latency budget of 150 ms., but on low-speed links the situation is very different. A single 1,500 byte packet on a 64 kbps link will push the latency beyond the 150 ms mark and even on a 128 kbps link, nearly two thirds of the total delay budget is consumed by just the transmission delay. This problem is compounded by the fact that compressed voice formats such as G.729 are more likely to be used over low-speed WAN links, and these algorithms contribute their own latency to the total end-to-end delay.
Even when voice packets are not blocked by data packets they are subject to their own serialization delay – the amount of time that is takes to clock the bits onto a serial link. Again, this delay is determined by packet size and link speed. Reductions in packet size result in less serialization delay and therefore, lower end-to-end latency. Another key performance metric is jitter. Jitter is the amount of variation in latency that is experienced over time. IP phones have some ability to buffer incoming audio streams to compensate for jitter, but excessive jitter can disrupt conversations. Again, the PSTN has virtually no latency and therefore no jitter, but enterprise IP networks are subject to jitter caused by congestion on LANs and WANs and by packet buffering in routers and other network devices.
The third important performance metric is packet loss. Since VoIP is a real-time audio service that uses UDP transport protocols, there is no way to recover lost packets. Packet loss can result in a metallic sound or dropouts in conversations that can be very frustrating to users. The PSTN experiences virtually no loss of digitized voice, but IP networks routinely experience packet loss due primarily to congestion. The key to meeting all of the VoIP performance requirements is adequate bandwidth, and the simplest solution is to throw bandwidth at the problem. This approach is being used successfully on enterprise LANs that have been upgraded to switched 100 Mbps and gigabit Ethernet. The real challenge is the wide area network. Private WAN facilities such as frame relay and private lines are very expensive and as a result most enterprise still have very limited bandwidth between their headquarters and their remote offices. Half of all WAN links between corporate headquarters and remote offices are 56kbps/64kbps or lower. Most other remote offices operate at speeds of 128kbps to 512kbps and fewer than 10% are T1/E1 or greater. How Expand’s ACCELERATORs Meet VoIP Performance Requirements Expand’s ACCELERATOR product line can help enterprises address the performance requirements of all enterprise applications including VoIP. First, ACCELERATORs change the economics of wide area networking by squeezing an average of 100% - 400% more bandwidth with peaks of 1000% depending on traffic mix. This frees up link bandwidth to support high quality VoIP services – and it does it without expensive WAN upgrades. It is also important to note that ACCELERATORs do not use lossy compression schemes that might degrade voice quality and they add less that one millisecond of latency.
In fact, the ACCELERATOR’s compression actually reduces end-to-end latency by reducing serialization delays on WAN links. For example, it takes 125 ms to serialize a 1,000 byte packet on a 64 kbps link, but if an ACCELERATOR increases the effective bandwidth by 4X to 256 kbps, the serialization delay is reduced by a factor of four to 31 ms. The following formula can be used to calculate the serialization delay for any combination of packet size and link speed: Packet Size (in bytes) x 8 / Link Speed (in kbps) = Serialization Delay (in ms) In addition to freeing up bandwidth normally consumed by data applications, ACCELERATORs are able to reduce WAN bandwidth requirements for different VoIP codecs. In tests that are described later in this paper, ACCELERATORs reduced G.711 bandwidth requirements by 20% and G.729 by 70%. As a result, WAN links can carry more simultaneous voice calls and the performance of other applications may also be improved.
ACCELERATORs solve increased jitter and latency caused by large data packets over slow WAN links by fragmenting large data packets and injecting VoIP packets at regular intervals. This feature allows VoIP and data to co-exist even on branch office WAN links. For example, normally, a VoIP packet “stuck” behind a 1,500 byte packet on a 64kbps lin will be delayed by 188ms (see table on page 3). Using the ACCELERATOR’s packet fragmentation will result in the data packet being reduced in size (accelerated - say from 1500 bytes to 500b bytes) and then fragmented into smaller data packets (say - 2 packets of 250 bytes each). In this case, the latency for the VoIP packet will go down from 188 ms to 31ms! In addition to increasing WAN capacity for both data and VoIP while reducing latency and jitter, ACCELERATORs also manage WAN bandwidth to ensure that critical applications like VoIP get the bandwidth they need. Expand’s ACCELERATORs include an Instant QoS feature that prioritizes application access to WAN bandwidth. Without such prioritization, the additional effective bandwidth provided by ACCELERATORs could be consumed by aggressive, non-critical applications such as file sharing. ACCELERATOR’s AppView feature provides graphical visibility for all application traffic sharing a link. AppView can be used to monitor WAN utilization and to plan future capacity requirements. And finally, ACCELERATORs have a set of data integrity features that are designed to stop the packet loss that can degrade voice quality. A flow control mechanism reduces packet loss caused by link congestion and a packet recovery feature ensures that any lost packets are transparently recovered at the link level before they can cause voice quality problems.
