VoIP bandwidth fundamentals Part II

Calculating the bandwidth for a VoIP call is not difficult once you know the method and the factors to include. The chart below, "Calculating one-way voice bandwidth," demonstrates the overhead calculation for 20 and 40 byte compressed voice (G.729) being transmitted over a Frame Relay WAN connection. Twenty bytes of G.729 compressed voice is equal to 20 ms of a word. Forty bytes of G.729 compressed voice is equal to 40 ms of a word.

The results of this method of calculation are contained in the next table, "Packet voice transmission requirements." The table demonstrates these points:

* Bandwidth requirements reduce with compression, G.711 vs. G.729.
* Bandwidth requirements reduce when longer packets are used, thereby reducing overhead.
* Even though the voice compression is an 8 to 1 ratio, the bandwidth reduction is about 3 or 4 to 1. The overhead negates some of the voice compression bandwidth savings.
* Compressing the RTP, UDP and IP headers (cRTP) is most valuable when the packet also carries compressed voice.




Packet voice transmission requirements
(Bits per second per voice channel)
Codec Voice bit rate Sample time Voice payload Packets per second Ethernet
PPP or Frame Relay
RTP cRTP
G.711 64 Kbps 20 msec 160 bytes 50 87.2 Kbps 82.4 Kbps 68.0 Kbps
G.711 64 Kbps 30 msec 240 bytes 33.3 79.4 Kbps 76.2 Kbps 66.6 Kbps
G.711 64 Kbps 40 msec 320 bytes 25 75.6 Kbps 73.2 Kbps 66.0 Kbps
G.729A 8 Kbps 20 msec 20 bytes 50 31.2 Kbps 26.4 Kbps 12.0 Kbps
G.729A 8 Kbps 30 msec 30 bytes 33.3 23.4 Kbps 20.2 Kbps 10.7 Kbps
G.729A 8 Kbps 40 msec 40 bytes 25 19.6 Kbps 17.2 Kbps 10.0 Kbps
Note: RTP assumes 40-octets RTP/UDP/IP overhead per packet
Compressed RTP (cRTP) assumes 4-octets RTP/UDP/IP overhead per packet
Ethernet overhead adds 18-octets per packet
PPP/Frame Relay overhead adds 6-octets per packet

The varying designs of packet size, voice compression choice and header compression make it difficult to determine the bandwidth to calculate for a continuous speech voice call. The IP PBX or IP phone vendor should be able to provide tables like the one above for their products. Many vendors have selected 30 ms for the payload size of their VoIP implementations. A good rule of thumb is to reserve 24 Kbps of IP network bandwidth per call for 8 Kbps (G.729-like) compressed voice. If G.711 is used, then reserve 80 Kbps of bandwidth.

If silence suppression/voice activity detection is used, the bandwidth consumption may drop 50% -- to 8 Kbps total per VoIP call. But the assumption that everyone will alternate between voice and silence without conflicting with each other is not always realistic. Silence suppression will be discussed in a later tip.

Most enterprise designers do not perform these calculations. The vendor provides the necessary information. The designer does have some freedom, such as selecting the compression technique for voice payloads and headers, and may be able to vary the packet size.



How can voice compression save bandwidth?
The Public Switched Telephone Network (PSTN) started with the transmission of analog speech. This worked well for decades until the areas under city streets became saturated with copper cables, one copper pair per call. Starting in the 1950s, AT&T Bell Labs developed a technique to carry more voice calls over copper wire. They developed digitized voice technology through which 24 digital calls can be carried on two pairs of copper wire, thereby increasing the carrying capacity of the cables twelvefold. The voice is digitized into streams of 64,000 bps per call. The technology is called a T1 circuit and the bandwidth for the 24 calls is 1.544 Mbps. This worked well for domestic connections. The T1 technology then became the mechanism for long-distance domestic transmission.

Most of the early voice compression technologies were designed for undersea cables, where bandwidth was limited and expensive. Voice compression technologies were created to reduce this bandwidth requirement. Voice compression is also used for digital cell calls, operating at about 8 Kbps instead of 64 Kbps. So voice compression is not new.

As the PBX market has moved into an IP-based environment, voice compression has become attractive for WAN transmission. Voice compression can be used on a LAN, but since LANs have so much available bandwidth, it is not commonly applied to the LAN.

The quality of a PSTN voice call provides enough analog bandwidth to understand the speaker in any language. It is also enough bandwidth for speaker recognition. The analog bandwidth delivered by the PSTN is about 3.4 KHz. This is considered toll quality. Voice compression can reduce the speech quality and may affect speaker recognition, so there is a limit to how much bandwidth reduction is possible before callers complain about voice quality.

The CODEC (COder/DECoder) is the component in an IP phone that digitizes the voice and converts it back into an analog stream of speech. The CODEC is the analog-to-digital-to-analog converter. The CODEC may also perform the voice compression and decompression.

There are several voice digitization standards and some proprietary techniques in use for VoIP transmission. Most vendors support one or more of the following ITU standards and avoid proprietary solutions:

* G.711 is the default standard for IP PBX vendors, as well as for the PSTN. This standard digitizes voice into 64 Kbps. There is no voice compression.

* G.729 is supported by many vendors for compressed voice operating at 8 Kbps, 8 to 1 compression. With quality just below that of G.711, it is the second most commonly implemented standard.

* G.723.1 was once the recommended compression standard. It operates at 6.3 Kbps and 5.3 Kbps. Although this standard further reduces bandwidth consumption, voice is noticeably poorer than with G.729, so it is not very popular for VoIP.

* G.722 operates at 64 Kbps, but offers high-fidelity speech. Whereas the three previously described standards deliver an analog sound range of 3.4 kHz, G.722 delivers 7 kHz. This version of digitized speech has been announced by several vendors and will become common in the future.

It is important to note that all of the voice digitization transmission speeds are for voice only. The actual transmission speed required must include the packet protocol overhead.

The quality of a voice call is defined by the Mean Opinion Score (MOS). A score of 4.4 to 4.5 out of a possible 5.0 is considered to be toll quality. Voice compression will affect the MOS. An MOS below 4.0 will usually produce complaints from the callers. Cell phone calls average about 3.8 to 4.0 for the MOS. The following table presents the voice MOS for different standard CODECs:

Standard Speed MOS Sampling delay per phone
G.711 64 Kbps 4.4 0.75 ms
G.729 8 Kbps 4.2 10 ms
G.723.1 6.3 Kbps
5.3 Kbps 4.0
3.5 30 ms

This table illustrates two points. First, as the voice is compressed, the voice quality (MOS) decreases. The MOS in the table does not include network impairments such as jitter and packet loss. These impairments will further reduce the voice quality. The VoIP network designer should choose a compression technique with a higher MOS so the network impairments will not reduce the voice quality to an unacceptable level.

Second, voice compression also adds delay to the end-to-end call. The table shows the sampling delay for one phone. This delay is doubled for the two phones of a call. This end-to-end delay needs to be limited. As compression increases, the delay experienced in the IP network needs to decrease, which increases the cost of transmission over the WAN, but not the LAN. The delays shown in the table are the theoretical minimum. The actual delays experienced will probably exceed 30 ms, no matter what compression technology is implemented. This delay will vary by vendor.

The conclusion is that digital voice compression is worth pursuing for VoIP transmission on a WAN, but it comes with some costs in voice quality reduction and increased end-to-end delay.