By Intel
Feb 11, 2000
IP telephony uses the Internet to send audio between two or more
computer users in real time, so the users can converse. VocalTec*
introduced the first IP telephony software product in early 1995.
Running a multimedia PC, the VocalTec Internet Phone* (and the numerous
similar products introduced since) lets users speak into their microphone
and listen via their speakers.
Within a year of its birth, IP telephony technology had caught
the world's attention. The technology has improved to a point
where conversations are easily possible. And it continues to get
better. Dozens of companies have introduced products to commercialize
the technology, and virtually every major telecommunications company
has launched research to better understand this latest threat
to their markets.
In March of 1996, VocalTec announced it was working with Dialogic
Corporation (Intel acquired Dialogic in 1999) to produce the first
IP telephony gateway. The original Internet telephone products based
on multimedia PCs are tremendous - offering the ability to combine
voice and data on one network. They also offer low-cost long distance
"telephone" service (assuming the user already has a multimedia
PC and a fixed-rate Internet service provider [ISP] account).
Gateways are the key to bringing IP telephony into the mainstream.
By bridging the traditional circuit-switched telephony world with
the Internet, gateways offer the advantages of IP telephony to
the most common, cheapest, most mobile, and easiest-to-use terminal
in the world: the standard telephone. Gateways also overcome another
significant IP telephony problem: addressing. To address a remote
user on a multimedia PC, you must know the user's Internet Protocol
(IP) address. To address a remote user with a gateway product,
you only need to know the user's phone number.
How Does It Work?
Conceptually, Internet telephone gateways work like this.
- On one side, the gateway connects to the telephone world.
It can communicate with any phone in the world. A phone line
plugs into the gateway on this end.
- On the other side, the gateway connects to the Internet world.
It can communicate with any computer in the world. A computer
network plugs into the gateway on this end.
- The gateway takes the standard telephone signal, digitizes
it (if it is not already digital), significantly compresses
it, packetizes it for the Internet using Internet Protocol (IP),
and routes it to a destination over the Internet.
- The gateway reverses the operation for packets coming in from
the network and going out the phone.
- Both operations (coming from and going to the phone network)
take place at the same time, allowing a full-duplex (two-way)
conversation.
A number of configurations can be built from this basic operation.
Phone-to-PC or PC-to-phone operation can take place with one gateway.
Phone-to-phone PC operation can occur with two gateways. To offer
international long distance service using gateways, for example,
an organization or service provider can host one gateway in each
country. By bypassing the international connect charges - even
paying in-country long distance rates - the configuration costs
significantly less than traditional circuit-switched service.
How Well Does It Work?
Nothing replaces trying it for yourself. However, we can make
some general observations. There are two main factors contributing
to quality: voice quality and turnaround time, or latency.
Voice quality has improved greatly from early versions of the
technology, which were characterized by distortions and disruptions
in speech. Improved technologies for voice coding and lost packet
reconstruction have yielded products where speech is easy to understand.
Latency affects the pace of the conversation. Humans can tolerate
about 250 msec of latency before it has a noticeable effect. Today's
IP telephony products exceed this latency, so most connections
sound like traditional calls routed over a satellite circuit (which
are usable, but require some getting used to). Even today, the
products are well suited to many applications. Moreover, the latency
will continue to improve, driven by three factors.
- Improved gateways. Developers are just beginning to
squeeze latency out of the first generation of products.
- Deployment over private networks. By deploying gateways
on private circuits, organizations and service providers can
control the bandwidth utilization and, hence, latency.
- Internet development. Today's Internet was not designed
with real-time communication in mind. The Internet
Engineering Task Force (IETF)*, together with
Internet backbone equipment providers, is addressing this with
technologies like Reservation
Protocol (RSVP), which will let bandwidth be
reserved. While it will take some time for the world's routers
to be upgraded and operational aspects (like how to bill for
high quality of service) to be resolved, the Internet word is
moving fast - and in the right direction.
Open vs. Proprietary
Systems
One of the key factors for IP telephony gateway developers to
consider is the value of open systems vs. proprietary systems.
It is tempting to develop proprietary versions of new technology
where off-the-shelf components are not readily available. However,
component vendors been able to respond to the demands of IP telephony
quickly, modifying existing products to address the needs of the
IP telephony gateway systems. These vendors are also continuing
to pour research and development money into enhancing their components.
The general advantages of open systems design are overwhelming.
Competition - at all levels - leads to lower prices, enhanced
features and continual innovation. Since system integrators need
to excel in fewer aspects of system design, costs fall even more.
The advantages of open systems are particularly compelling for
IP telephony. The impact of the Internet on telephony is not as
a standalone system or feature. It is fundamental and systemic.
New generations of telephony systems will evolve to better incorporate
Internet capability. These new generations will be built using
open systems and standards.
Choosing a Component
Supplier
To build open systems, system integrators must choose component
vendors with products that meet their technical requirements.
Even more important, the component vendor must be committed to
this new market and must demonstrate the ability to adapt to its
changing requirements. And since so many IP telephony systems
are global, the vendor also needs a worldwide network of service.
Architecture
For telco-grade installations, system integrators will consider
VersaModule-Europe (VME) or Compact Protocol Control Information
(PCI) system designs. Using equipment that meets Bellcore*
Network Equipment Building Standards (NEBS)* will improve the
installation and maintenance in many facilities. Customer premise
equipment (CPE) can be hosted in an Industry Standard Architecture
(ISA) or PCI chassis. Windows NT* and UNIX* are both suitable
operating system choices.
Telephone Interface
The telephone connection of the gateway needs to exhibit two
critical features.
- There must be approved versions in all major countries,
since the largest cost savings for IP telephony is on international
calls.
- It must be scalable. Depending on the design goals
of the system integrator, systems might range from two lines
for small enterprises to several thousand for service bureaus.
Call Control Protocol
The first IP telephony products used proprietary call control
protocols. H.323, however, is clearly emerging as the standard
call control protocol. This specification defines packet standards
for terminal, equipment and services for multimedia communications
over large area networks (LANs) communicating to systems connected
to telephony networks such as ISDN. It will be supported by successful
IP telephony products.
Voice Coders
Key technical requirements for coders include:
- Low bandwidth (8 kp/s or less)
- High quality for voices (3.5 mean opinion score (MOS) rating
or better)
- Low latency
- Ability to reconstruct lost packets
In real-time transmission, up to 30% of the packets in a transaction
might be lost or delayed (which is the same as lost in real time).
Successful IP telephony applications, then, need to recover from
lost packets by effectively reconstructing the lost data. The
complexity of the coding algorithms has an impact as well. High
complexity increases the cost of the host platform.
G.723.1 is emerging as a popular coding choice. G.723 is an algorithm
for compressed digital audio over telephone lines. The enduring
requirement for coders, however, is that IP telephony systems
be capable of supporting multiple coders and adding more as technology
emerges and popularity changes.
Echo Cancellation
The Internet telephony gateways must perform echo cancellation.
In a typical configuration, two gateways are each connected to
analog phones via a digital, local central office (CO) switch.
The phone system generally does not perform echo cancellation
on local circuits. Echo is present (caused by the four-wire to
two-wire hybrid), but is not a problem on local calls. The latency
is not long enough for the echo to come back as a separate transmission.
The phone system does perform echo cancellation on long distance
circuits. By the time the echo propagates through the network
back to the speaking part, it is quite disruptive.
IP telephony represents a unique case. Technically, local connections
are being used. Hence the phone system itself is not performing
echo cancellation. But long distance calls are being made. Hence,
the echo will disrupt conversations if it is not canceled. The
IP telephony gateways, then, must supply the echo cancellation.
Full Duplex
Phone calls are full duplex, meaning both parties can speak at
the same time. Successful IP telephony products are also duplex.
Surprisingly, not all voice cards can support full-duplex operation.
DTMF Detection and Notch-Out
Dual-tone multifrequency (DTMF) digits do not travel well across
the Internet. Coding and packetization distorts and segments them,
making them unrecognizable on the remote end. IP telephony gateways,
then, must detect DTMF digits locally, suppress their transmission,
then generate them on the remote side.
*All company names, products, and services mentioned are the
trademarks or registered trademarks of their respective owners.
© 2001 Intel Corporation
