How voice compression saves bandwidth

Compression of voice traffic can save bandwidth on your IP network, but can cost quality or cause delays. Learn more about the CODECs or standards for voice compression -- and their effect on call quality -- in this tip.

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. See What's in a voice packet: An introduction to bandwidth for VoIP to learn more about the packet overhead. A 64 Kbps call with overhead included requires about 80 Kbps bandwidth in total. There will be more on this subject in the next tip, "Calculating voice bandwidth consumption."

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

About the author:
Gary Audin has more than 40 years of computer, communications and security experience. He has planned, designed, specified, implemented and operated data, LAN and telephone networks. These have included local area, national and international networks, as well as VoIP and IP convergent networks in the U.S., Canada, Europe, Australia and Asia.

This was last published in January 2007

Dig Deeper on VoIP QoS and Performance



Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.