TMCnet - World's Largest Communications and Technology Community




FeatureArticle.gif (4903 bytes)
July 1999

Making Voice Fit Into The Data Network Puzzle


Voice-over-data network technology has progressed to the point where operational cost savings can easily offset equipment acquisition costs. Although not inherently optimal for real-time voice, IP networks are ubiquitous and inexpensive. Standards exist to offset the connectionless, best-effort delivery nature of IP, and the considerable control MIS managers have over corporate IP networks to increase their suitability for voice. However, the packaging of voice-over-IP (VoIP) technology has yet to address the issues of preserving the value of existing equipment and maintaining the ability of users to employ it efficiently. The use of gateways between conventional PBX equipment and the IP network can preserve the comfort of users, and allows fallback to traditional operation in the event of problems.

Any examination of fundamental operating costs reveals that the technology of carrying live voice conversations over packet data networks is mature. As compared to the fixed 64 Kbps in each direction of the conventional circuit-switched digital telephony network, packet network telephony equipment greatly reduces the transmission capacity needed per call.

Codecs, the devices or software that code and decode analog voice signals into digital data, are now in their third generation. Waveform codecs, which are still used for their fidelity when network bandwidth is plentiful, achieved either no data rate reduction or a factor of two to four with some loss of speech quality. Block codecs reduced the data rate further, but at a greater quality loss. Today’s hybrid codecs, such as G.729a and G.723.1, provide both low data rates and high quality. Block coding techniques are still used — that is, a segment of speech is reduced to a set of numerical parameters. When processed by the decoder, these result in a signal that is perceived in the same way as the original by a human listener. However, hybrid codecs generate multiples of such parameter sets and choose the best to send based on how closely the decoded signal approximates the input waveform.

The standards for codecs frequently include sections or annexes that describe an algorithm for Voice Activity Detection (VAD) and Comfort Noise Generation (CNG). For example, G.729b provides this for the G.729 codec (of which G.729a is a lower-MIPs variation). By filling gaps in a conversation with compact and infrequent descriptions of the background noise level, the amount of data is further reduced. Assuming that only one party speaks at a time, and allowing for normal conversational pauses, a reduction of a factor of three can be expected.

Combining an aggressive codec such as G.723.1 at 5.3 Kbps with VAD/CNG, an average data rate of less than 2 Kbps can support a high-quality telephone conversation. Multiplexing many such conversations onto a packet-switched data network will smooth out burstiness as voice and silence alternate on each call. Allowing for some residual burstiness and protocol overheads, it is still clear that a digital transmission facility with a given bit rate will carry 20 to 30 times as many conversations using packet network telephony technology as conventional technology.

Based on these advances for voice-over-data technology, the major obstacles to the adoption of packet network telephony must be other than technological. In cases where compelling new technology is not immediately accepted as a replacement for old, the same two factors are usually present: First, users are unwilling to replace existing equipment before it has reached the end of its life cycle. Second, adoption of new technology can give rise to training and support costs, and a short-term loss of productivity as users become familiar with it.

MIS managers, however, cannot afford to pass up the potentially huge cost savings of redirecting corporate telephony over packet data networks. What is needed is a strategy that makes maximum use of existing equipment, and requires little or no change in the habits of users. It would also be beneficial if providing data network access for telephony could be combined in some way with established data network access, such as remote user dial-in. This spreads the cost of acquisition, installation, and maintenance over a broader range of service users.

Much of the development of packet network telephony took place with the intent of applying it to connection-oriented data networks such as frame relay and ATM. The explosive growth of the Internet, however, has made connectionless IP networks by far the most widely available. Such a network poses additional problems for voice transmission with its inherently real-time characteristics. The IP community and the Internet Engineering Task Force (IETF) have addressed these issues in a number of RFCs, which are in various stages of the standardization process.

Real-Time Protocol (RTP) (RFC 1889) provides the basic mechanism for transmitting data with real-time requirements over a connectionless, best-effort delivery network such as an IP network. It allows packets to be re-timed at the receiver so as to reconstruct the transmitted data in (delayed) real time. The loss of packets in the network can be detected by missing sequence numbers.

Whereas RTP can be deployed immediately in network edge equipment, it cannot change the nature of the network itself. ReSerVation Protocol (RSVP), however, does exactly this. By reserving bandwidth in network nodes (routers) and transmission facilities, telephony terminals can expect a consistent quality of service (QoS) without the variable delays and packet discards usually associated with an IP network over long distances. To be effective, however, RSVP does need to be implemented in all routers along the path of the telephony call.

IPv6 incorporates QoS provisions directly in the Internet protocol itself. As with RSVP, it must be implemented along the path taken by packets. Unfortunately, its deployment seems to be slow at present.

Although connectionless, best-effort delivery can clearly cause problems for voice on the Internet at large, MIS managers have greater control over a corporate IP network. Fewer routers, more predictable load patterns, and careful management can make such a network far more suitable for real-time traffic.

For voice-over-data traffic, Internet telephones replace conventional telephone terminals, and connect directly to an IP network instead of a corporate PBX. Although manufacturers take care to make IP phones as similar as possible to the desk telephones users are familiar with, feature and operational differences do arise. If a user is, for some reason, uncomfortable with the new technology, it is not possible to place calls over the conventional telephony network. With the assistance of a voice gateway, a PBX can make use of IP telephony without changing the users’ terminals. All existing features of the office telephone system remain undisturbed, but the ability to route calls at negligible cost over the corporate data network is added.

The PBX can be connected to an external voice gateway device just as it can be connected to the T1/PRI carrier transmission facility. Alternatively, the PBX can incorporate the gateway functionality and have a direct connection to the IP network. In some cases, traditional manufacturers of PBX equipment may be unfamiliar with IP telephony technology. Some companies are providing highly integrated modules that obviate the need for PBX vendors to develop codec, network delay compensation (jitter buffer), and RTP technology.

Most corporations with data networks provide access to those networks from remote locations. The most common method is dial-up access from modems and/or ISDN terminal adapters. This works well for branch offices, which can use multiple, bonded ISDN BRI lines to field personnel calling from the modems in their portable computers.

There is a similarity between accessing a network from a remote location for data and accessing the network for the transmission of voice. In both cases, the connection comes from a 64 Kbps DS0 or bearer channel. For remote data access, the DS0 carries data directly (ISDN), or indirectly by coding (V.90) or modulation (V.34, etc.). For telephony access, the DS0 carries the analog voice waveform.

The usage pattern of corporate networks usually varies with time. During the day, telephony is heavily used, and data users are directly connected or busy with customers. During the evening, telephony use dies down as people return to their homes and remote data access ramps up as they dial in to do a little extra work and field personnel return to their hotel rooms.

An ideal data network access device would service ISDN, data, facsimile, and voice calls on all ports. This would allow the MIS manager to deploy only the peak number of ports needed and use them differently at different times. The infrastructure for the VoIP network can also be put in place on equipment that is already able to pay its way for remote data access. Although much existing equipment is capable of data access or voice access — but not both, new soft architectures allow any port to service any kind of call.

By using universal access port architectures, the voice-to-IP gateway can also serve as a remote access gateway — further diluting the risk of new technology adoption. The availability of highly integrated hardware/software modules allows the traditional vendors of corporate telephony equipment to add VoIP without the cost and risk of internal development.

Graham Davies is a senior member of the technical staff for Mapletree Networks. Mapletree provides leading edge internetworking and remote networking core technology for the high-growth remote access and NT remote access server market, including access solutions for telcos, carriers, ISPs, and large enterprise customers. Founded in 1997 by former executives of Microcom, Inc., Mapletree Networks is headquartered in Westwood, Mass., and has a European office in the UK. More information is available on the company’s Web site at www.mapletreenetworks.com

Is IP Telephony Too Much To Process?


Does it seem like we hear more about IP telephony and less about true convergence these days? Most providers are deploying dedicated IP telephony networks, separate from data. In still-running parallel networks, cost savings lags behind what it could be. What’s happened?

Simply stated, the rubber has met the road — and the road is harder than first assumed. Industry forces concur on the mission: Increased speeds and more varied types of traffic on IP-based packet networks. They even concur on the milestones: Increased speed with reduced delay, deploying IPv6, providing PSTN-level quality of service (QoS) with Service Level Agreements (SLAs), supporting standards such as DiffServ, MGCP, H.323, and so on. But all of this is easier said than done. And from the standpoint of provider profitability, IP telephony carriers need more intelligence in the network for least-cost routing, accurate billing, and expanded feature sets.

Even though everyone seems to agree on what needs to happen, few are talking about how it will happen. And “how” is the key.

A major change needs to take place across the industry if IP telephony, much less convergence, is to keep its promises. True policy-based networking is needed to support IPv6, DiffServ, and speed increases already on the horizon. A new generation of networking equipment must be created to process different types of traffic more cleanly, and at unprecedented speeds.

To rev up equipment and keep pace with these changes, major equipment vendors must upgrade their packet processing systems, effecting more comprehensive processing at faster speeds. This represents a huge development effort that could take dedicated R&D groups two years to complete. Rather than mount such an ROI-compromising campaign, many will use core technologies that have already been focusing on the processing issue for years. One way or the other, major strides in processing should precede the next wave of IP industry developments such as DiffServ and IPv6.

One way advanced processing can accommodate higher speeds is by eliminating delay in classifying thousands of RTP flows comprised of UDP packets. These flows are uniquely identified by a pair of IP addresses and UDP ports. With VoIP, port associations change dynamically. Instead of having to repeatedly wait to decipher intelligence within the application, a better processing approach can identify the packets belonging to the flow in real time as they come off the wire. The trick is to do as much of the classification as possible in hardware without having to add ridiculous amounts of CPU power.

Striking an efficient division of labor between hardware and software within the chips and NICs is an underlying strategy in the design of Solidum’s PAX Packet Description Language and other worthwhile alternatives to today’s processing technology. Besides playing a key role in classifying RTP flows at wire speed, the increased hardware force impacts support of emerging standards.

A Different Process For DiffServ
DiffServ (DS) support relies on multi-field (MF) classifiers. The fields typically denote source IP addresses, destination IP addresses, Type of Service (TOS) bytes, and UDP or TCP ports. In accordance with the RFC 2474 prescription for DiffServ, edge devices need to MF-classify in order to mark packets by replacing TOS bytes with DS bytes. RFC 2475 further suggests that devices should allow for maximum flexibility. But again, the classification criteria are difficult to predict. Once again, more potent processing is required to affect classification the instant information is received about the nature and priority assigned to incoming packets.
IPv6 Raises the Stakes

With IPv6, Layer 3 headers have variable lengths, depending on the number of optional subheaders used. Parsing, or protocol demultiplexing of IPv6 headers, is therefore more time-consuming then with IPv4 if attempted in software as occurs today. IPv6 addresses are also much larger, a hefty 128 bits to IPv4’s 32. Today’s approach of using Contents Addressable Memory (CAM) technology to do lookups can easily become strained in the face of such greatly increased overhead. Shifting the hardware/software balance would require significantly more silicon using today’s equipment architectures, a caveat that would drive manufacturers’ costs way up.

A new approach to classification uses programmable state machine technology. This architecture allows the use of a non-procedural programming model. Such a solution helps to eliminate processing delays, and programming becomes a snap, cutting development time.

“Internet time” is a phenomenon, not myth. Whatever method manufacturers opt for in advancing processing, plans should be leaving the drawing boards now. When DiffServ and other advances can be truly implemented, IP telephony will cease to mean savings alone. It will start to mean profits.

Misha Nossik is co-founder and CEO of Solidum Systems Corp. Solidum supplies core chip technology and hardware/software solutions for advanced Internet packet processing. For more information, visit the company’s Web site at www.solidum.com

Version 3 Of H.323: Will It Answer The Interoperability Call?

Interoperability in the voice/data convergence marketplace can be as confusing as the various network topologies and equipment offerings available to implement this burgeoning technology. While many protocols have risen to prominence in the industry, the International Telecommunication Union’s (ITU) H.323 recommendation has been the benchmark for all the major players. If your voice-over-IP product is not H.323 interoperable, you might as well go back to the drawing board.

Version 2 of H.323 — the present standard for IP telephony products, has been praised and criticized on many levels during the few months since it was announced. This version puts the emphasis on voice for the H.323 protocol, rather than the multimedia compatibility stressed in the first version. Now the ITU is discussing Version 3 — the next level of interoperability, and made determination on the protocol and ratified several important annexes to it at Study Group 16’s May meeting in Santiago, Chile.

According to Michelle Blank, vice president of marketing for H.323 protocol stack developer RADVision , Version 3 “is really geared to supporting large-scale commercial production networks.” The ultimate goal of the protocol, of course, is to allow interoperability among equipment from any vendor that supports its requirements. The key, however, is to get vendors to agree on which set of requirements to support.

Dale Skran, rapporteur for the study group’s question 13, which focuses on packet-switched multimedia systems, said the following annexes and complements to Version 3 were ratified at the May meeting:

  • Annex E. This provision discusses sending signaling over User Data Protocol (UDP) instead of TCP/IP, for quicker call establishment. It would not replace TCP/IP, however.
  • Annex F. Otherwise known as Simple Endpoint Type (SET). This annex would replace the single-use device (SUD) concept from Version 2, in which intelligence resides in the network and endpoints. Intelligence would shift to central network devices, leaving a simpler endpoint.
  • H.450.4-7. These four computer telephony enhancements include call holding, park and pickup, call waiting, and message waiting.
  • H.341. This addition focuses on extending the capabilities of the gateway multimedia management information base (MIB).
  • H.245, Version 5. This protocol governs embedded tunneling for minimal call signals and a faster connection.
  • Version 3 of H.323 was determined at the May meeting, meaning it has passed the initial stage of approval.

The following annexes were also determined, according to Skran:

  • Annex G. Geared toward large-scale enterprises, this annex governs inter-domain communications, and basically groups several zones (the areas controlled by a gatekeeper) as a domain. The annex focuses on address resolution among domains.
  • H.GCP. Perhaps one of the most important provisions to be determined, H.GCP breaks up a gateway into a decomposed architecture whereby the media gateway (MG), and the media gateway controller (MGC) are treated as separate components.
  • H.450.8. This additional telephony feature would add name identification services to the protocol.
  • H.225, Version 3. Covers text-based chat using simple endpoints.
  • H.245, Version 6. Governs the definition of H.245 codepoints
  • H.246, Annex C. Covers ISUP-H.225.0 interworking.

The Internet Engineering Task Force’s (IETF) Media Gateway Control Protocol (MGCP) utilizes the H.GCP concept, and some vendors believe this approach is in fact more efficient than H.323. AudioCodes , maker of voice processing trunk pack boards, has traditionally supported H.323, but has come out with a board that will support MGCP. The TrunkPack/VoIP-200 voice board will divide voice transmission functions between audio streaming and a separate gateway control agent.

Oded Morag, AudioCodes’ director of marketing, says MGCP makes it much easier to implement standards for fax over IP, as well as SS7 connectivity. He views MGCP and the drive for interoperability as a reaction to Linux and the movement toward open sources for the computing industry in general. Ultimately, vendors will push MGCP, H.323, or whatever protocol ends up winning the interoperability war, says Morag. The ITU is scheduled to meet in February of 2000 to ratify Version 3.

Technology Marketing Corporation

2 Trap Falls Road Suite 106, Shelton, CT 06484 USA
Ph: +1-203-852-6800, 800-243-6002

General comments: [email protected].
Comments about this site: [email protected].


© 2023 Technology Marketing Corporation. All rights reserved | Privacy Policy