Tuesday, July 25, 2006

Insights On Bandwidth Requirements For A Business VoIP System

How Much Bandwidth Is Required To Deploy VoIP For Business Applications?

This is the most commonly asked question on a VoIP network. That's because voice is much more sensitive to traffic congestion, on the network, than data. When implementing VoIP over a LAN, you obviously have much more bandwidth at your disposal. Therefore, you can configure VoIP devices to use a more bandwidth-intensive codec, such as the G.711, which consumes up to 87.2 kbps of NEB (Nominal Ethernet Bandwidth) in one direction. This will ensure better voice quality. In addition to this, you would also need to analyze the existing traffic patterns on your network. If it's already congested with a lot of broadcast traffic or other bandwidth-intensive applications, then the response time would be higher. This in turn will affect the voice quality of VoIP calls. You might face breaks or choppy voice due to this.

One common misconception about VOIP is that it is a bandwidth hog, when, in fact, voice is a very efficient type of traffic. Voice compression standards like G.729 (8:1) and G.723 (10:1) are used to minimize the bandwidth required for voice. G.723, for instance, is the maximum compression rate and requires only 5.3K bps (plus an added 7-8K bps for IP overhead). Even at maximum compression, your VOIP solution will still provide near toll-quality voice.

As a rule of thumb, 14K bps of bandwidth per call is ideal. This includes the compressed voice packet and the IP overhead. To determine total VOIP bandwidth needed per location, take the number of VOIP channels being used and multiply by 14K bps. Then double this number to accommodate for both voice and data traffic.

It should also be noted that bandwidth is used only when someone is speaking. A silence suppression/Voice Activation Detection (VAD) feature is an option that frees unused call bandwidth for data traffic. This is significant, since callers are usually silent for 60 percent of the call.

An easy tool you can use for both planning and system checkups....for free....is this "Lines To IP Bandwidth Calculator" from WestBay: IP Bandwidth Calculator

Another good bandwidth calculator is found at voip-calculator.com.

There are also several good software tools that can help you. Check out ixiacom.com, which has some specific tools to help you with VoIP deployment. Plus, they even have other tools to help you calculate the response time and throughput on your network.

While deploying VoIP on LANs, experts recommend that you create a separate VLAN (Virtual LANs) on your network for IP telephony. This will keep the voice and data networks separate, and anything happening on one will not affect the other. For this, you'll also have to ensure that you're using manageable switches on your network, which support VLANs. Having a separate VLAN will also ensure that your VoIP network remains unaffected from security threats that might occur on the data network. A DoS attack for instance, would affect a VoIP network much more adversely than a data network.

The key issue in deploying VoIP over WAN links is that you have limited bandwidth. So you have to start by determining how many simultaneous voice calls you'd want to hold over your WAN links. Then determine how much bandwidth would be consumed by each voice call. For this, you have to take into account the compression technique to use, the payload size of voice packets, and the type of link used for VoIP communication. There are a lot of different codecs that can be used for VoIP communication, supporting bit rates that range from 5.3 Kbps to 64 Kbps. Using the codec data along with the payload size and type of link, it's possible to calculate the amount of bandwidth required per call. You'll also find a lot of bandwidth calculators available on the Net to help you with this job (such as the examples above).

A Critical Factor Is Ensuring Quality of Service

Once you have calculated the bandwidth required for VoIP, you have to ensure you're your voice calls get that much bandwidth. This is when you have to enforce the QoS policies, else, you will get poor quality reception, delays, jitters, missed speech or even dropped calls. Typically toll quality calls require at least 16-20 kbps of bandwidth. QoS is normally controlled at the router level. Therefore, you'll need a router that let's you configure QoS for VoIP packets on your WAN links.
You can also deploy switches that support QoS for VoIP on your LAN. There are also some bandwidth-management solutions available that support QoS policies.

Now For The Details Behind The Scenes

Remember.....the techie details ARE important, but NOT overwhelming.

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 actual 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 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. 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 enterprises 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.

So What's The Solution?

Now, all of this may seem overwhelming and utterly impossible to implement for your organization. Not so. You and your IT staff need not experience high blood presure and assorted other health ailments while planning, designing, and implementing a VoIP system. Simply take advantage of the free consultation available through Business VoIP Solution and you can rest easy knowing everything will be taken care of.

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home