Voice over IP’s dirty little secret is that it can be a bandwidth hog.
Observers warn that customers looking to use Voice over IP had better plan to significantly bolster bandwidth and look hard at voice compression technology before making a commitment. While money can be saved with Voice over IP by skirting intracompany long-distance charges and consolidating voice and data WAN circuits, users should be aware that as much as two-thirds of a T-1 line’s bandwidth can be consumed by IP overhead – headers and error correction bits – depending on the type of Voice over IP codec used.
Standard speech-encoding algorithms, or codecs, are defined by the International Telecommunication Union, and specify the speed and compression of packetized voice traffic. Common codecs are G.711, a noncompression codec used in 64Kbps video and voice conferencing applications, and G.728 and G.729a, which can reduce bandwidth consumption to as little 16Kbps and 8Kbps.
Most corporate- and carrier-class Voice over IP equipment, including gateways, IP phones, IP PBXs and videoconferencing equipment from vendors such as Cisco Systems Inc., Nortel Networks Corp. and Lucent Technologies Inc., employ these ITU codecs in hardware and software to transmit packetized voice signals over data
networks.
When choosing a codec for your Voice-over-IP network, it is important to consider how your compression method will affect the ratio of IP packet overhead data to actual voice frames per packet, said Scott Hamilton, IP telephony track manager for Tolly Research in Manasquan, N.J.
Tolly Research recently measured the performance of voice traffic on a T-1 line with G.711, G.728 and G.729a codecs applied to the traffic. Using two voice frames per packet, uncompressed G.711-encoded traffic averaged about 110Kbps, even though the ITU defines G.711 as 64Kbps (the same rate as a digital phone line in a standard voice T-1 circuit). That means 46Kbps of a T-1 is consuming IP overhead.
“Users should not assume that allocating a T-1 equivalent [for G.711 Voice over IP] on their data network will be sufficient,” Hamilton said. “It’s going to be close to double that.”
While G.711 does not provide compression, Tolly Research found that compressed G.728 and G.729a traffic was also bogged down by IP packet overhead. In all three codec tests, the group found that up to 80 per cent of the bytes in the voice packets consisted of IP packet overhead.
“If someone picks G.728 and thinks they’re going to get four times the compression, they’ll only get four times compression with respect to the actual voice frame,” Hamilton said.
According to Tolly’s test, G.728 packets with two voice frames will consume 62Kbps instead of 110Kbps with G.711. “That’s only a two-to-one savings,” he adds. “Relative to the 64Kbps that are used [in one channel of a traditional circuit-switched T-1], there’s no savings at all.”
The First American Corp., a firm that provides credit information to banks, is rolling out a Cisco Architecture for Voice Video and Integrated Data (AVVID) IP telephony system. Ahmad Sidani, a senior network engineer for the firm, said that in addition to using the quality-of-service features of his Cisco LAN and WAN equipment to prioritize voice traffic, he is also scrutinizing which ITU compression standard he will use.
“Once we identify exactly what the pattern of the [Voice-over-IP] application is going to have, we can then go and identify which [codec’s] compression method is more feasible based on the quality we want,” Sidani said.
T-1 lines will be used to connect AVVID call servers and IP phones in the branch offices to a PBX in its Santa Ana, Calif., headquarters, Sidani said. Although he would like to use G.711 for the highest voice quality, he will not know if this is feasible until the AVVID gear is tested with voice and data occupying the same trunk. Sidani adds that he is aware of the extra overhead traffic that is generated when voice is packetized, but he wants to measure the actual performance to determine the sufficient bandwidth for his branch offices.
“We definitely have to do an analysis of the different compression [codecs] before we deploy,” Sidani said. “The number of users floating across our WAN will vary from office to office, and their data and voice needs are going to be different in each office.”
Remembering to factor in IP packet overhead when voice is packetized is something that can be overlooked by some users, said Brian Dal Bello, manager for Nortel’s Succession enterprise voice-over-IP product line. If miscalculated, this can sometimes erase any planned cost savings of a Voice-over-IP rollout, he adds.
“When Voice over IP goes into an enterprise, people have to understand all the variables that can affect their bit rate and calculate if they’re actually saving bandwidth or money by using [Voice over IP],” instead of traditional voice, he said.
From the deployments Dal Bello has seen with customers, he has noticed a trend in codec use – G.711 in LANs where bandwidth is plentiful and G.729 for WANs.
Other Voice-over-IP equipment vendors are working to unload the inherent baggage that accompanies voice-over-IP packets.
“If you can aggregate packets and put a common address in front of them, you can reduce the overhead associated with sending voice over an IP network,” said Heidi Bersin, marketing vice-president for Clarent, a maker of carrier and enterprise Voice-over-IP gateways. “It’s sort of like the multiplexing of packets.”
Clarent uses proprietary technology it calls ThruPacket, which sends Voice-over-IP packets along as links in a chain instead of each packet having its own addressing info. A small amount of data is inserted into each packet in a ThruPacket chain, which identifies the packet as a chain “link.” Only the lead packet in the chain contains the IP packet overhead data [including Ethernet and IP addresses] that can cause congestion and latency in normal Voice-over-IP networks. ThruPacket is present in the company’s carrier-class Gateway 400 and 1200 and its Gateway 100 for firms.
Some network professionals would prefer to avoid the problems with Voice over IP and use other technologies for converging voice and data, such as ATM.
“I still say you can’t beat ATM for voice” in a WAN, said Steve Hays, IS director at G.A. Sullivan, a St. Louis software company.
Hays has a Sphericall LAN telephony system from Sphere Communications Inc. in his central office and uses ATM to connect to Sphericall equipment in eight remote offices via T-1 lines.
Hays is looking into an IP version of the Sphericall product, but is not rushing to replace ATM with IP for his long-distance telephone trunks.
“You can get a lot of latency on your voice network just because of the IP characteristics,” he said. “I don’t know if there is a good way you can control it.”
