July 1999
Making Voice Fit Into The Data Network Puzzle
BY GRAHAM DAVIES
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.
VOICE OVER DATA MATURES
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. Todays 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.
PRACTICAL DEPLOYMENT
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.
IMPLEMENTING STANDARDS
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.
TERMINAL EQUIPMENT
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.
UNIVERSAL ACCESS PORTS
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
companys Web site at www.mapletreenetworks.com
|