October 1999
Guidelines For Choosing An IP Telephony Gateway
BY JITENDRA SHEKHAWAT AND PATRICK NOON
Starting from its initial attractiveness in providing toll bypass for long distance
calls, IP telephony has developed into a key set of enabling technologies for the
convergence of the PSTN and data networks. An integral part of such converged systems is
an IP telephony gateway, which bridges the traditional PSTN network with the data network.
In this article we will explore the critical design parameters, trade-offs, and technical
requirements to consider when selecting a IP telephony gateway that meets both business
and technical goals.
BASIC BUILDING BLOCKS
A IP telephony gateway interfaces to the PSTN network on one side and to the data network
on the other side. The gateway hosts a broad set of voice processing and media conversion
functions whose purpose is to interact with the caller, forward the call, and convert
voice data between traditional formats (generally PCM digital data to packet data).
In the sections below, we describe the salient features of each of these basic building
blocks and raise some key questions to consider before purchasing an Internet telephony
gateway.
PSTN Interface
When selecting gateway software and hardware, consider different types of PSTN
interfaces, number of channels supported by the gateway, and supported features for
problems unique to PSTN/IP gateways. Some of today’s PSTN interfaces are:
- Robbed-bit T1.
- E1 R2MF.
- T1/E1 ISDN PRI.
- SS7.
- POTS (analog).
For example, your corporate headquarters may have a T1 ISDN PRI line whereas a remote
office may have analog lines. It is desirable to use the same gateway software to make
maintenance and administration tasks easier.
Generally, there are two gateway configurations for the PSTN side: either the gateway
is directly attached to the PSTN or is indirectly attached through a PBX. Regardless of
the configuration, a gateway needs to get a call’s destination address either
interactively from the user or via DNIS from the originating equipment (CO switch). If the
gateway is attached directly to the PSTN, answer supervision is critical. What does the
caller hear as the call progresses from PSTN to IP to PSTN? Some gateways don’t
provide audio feedback (in-band audio/call progress tones, such as the ring cadence) to
the caller. This feedback is critical since IP telephony calls can take longer to
establish than PSTN calls.
Voice Processing
Probably the biggest difference between IP telephony gateways is the degree to which they
provide voice processing functions, such as IVR prompting for inbound callers. Such
features often make the difference in ensuring call completion and customer satisfaction.
In analyzing the voice processing capabilities of a gateway, the first step is to
determine which of the following basic features (and each of their capabilities) are
provided:
- Playing files (instructional prompts, tones, etc.).
- Recording conversations.
- Detecting digits.
For example, what file formats (e.g., PCM, ADPCM, .WAV) are supported in playing and
recording? Can user digits be detected and sent out-of-band — as a message instead of
as audio — to a destination IP gateway to maintain digit integrity? Can custom tones
be defined and detected if the gateway is connected to a PBX with custom supervision
tones?
For gateway selection, two additional points should be considered.
First, do all the advertised voice processing functions apply both to PSTN callers and IP
callers, without any restrictions? Given the parametric nature of Internet communications,
almost all gateway users need the ability to record conversations on both the IP and PSTN
sides at some point in their deployment phase. If this record capability is available,
recordings can be analyzed for voice quality as a function of coder type and bandwidth at
different times of the day.
Second, since other hardware may be required to implement the voice features, one may
often find that the channel density of a gateway is highly influenced by the use of the
voice processing functions.
Media Conversion
The heart of a gateway is its ability to convert voice data to and from packet
data. The basic functions required to do this are:
- Echo cancellation.
- Voice coding.
- DTMF suppression.
- Packet resequencing.
Echo cancellation is needed to remove the far-end echo. Although all gateways
invariably provide this function, the amount of echo removed (in time) and the quality of
its removal are highly variable. A very useful feature is the ability to configure or tune
this sub-function for your specific situation.
Voice coding is done to conserve the required bandwidth on the LAN/WAN. Since coding
trades voice quality for bandwidth, it is advantageous if your gateway supports a family
of coder types to meet all situations. Moreover, the best gateways provide the ability to
adjust basic parameters for each coder type. For example, they should support a range of
frame sizes and frames-per-packet selections. Other desirable coder features to look for
are silence suppression (i.e., sending no audio when silence is present) and comfort noise
generation (i.e., injecting noise into an audio stream instead of dead silence). Check if
the gateway can be dynamically adjusted to enable and disable these features.
DTMF suppression is optionally done by gateways since the low-bit coders generally do
not adequately represent digits. Thus, most originating gateways remove the dialed digits
from the audio stream flowing into the IP network and send an out-of-band message to the
destination gateway. The destination gateways then regenerate and merge the dialed digits
with the audio before retransmission in the PSTN. Although sending DTMF digits out-of-band
is supported on most gateways, it is imperative to verify this. Furthermore, determine if
it is possible to dynamically adjust the gateway’s DTMF transmission mode between
in-band and out-of-band.
Packet resequencing is done by a gateway on its receive side since audio streams over
IP use User Datagram Protocol (UDP). Therefore, packets can arrive out of sequence or not
at all. By maintaining a so-called “jitter” buffer to store a history of
received packets, gateways attempt to re-order the data to its original time-stamped
positions at the expense of added latency. Clearly, since IP network conditions are
somewhat volatile, it is crucial that a gateway provide the ability to change these buffer
sizes dynamically.
Data Network
Supporting a set of IP “channels” requires that sufficient data network
bandwidth be available. To get a rough estimate of your bandwidth requirements consider:
- Bandwidth required by lowest bit-rate coder.
- Bandwidth required by highest bit-rate coder.
- Number of IP channels.
- Bandwidth required by other applications running on your gateway platform.
To calculate the bandwidth, we first determine the basic size of an audio packet.
Noting that H.323 audio streams over IP use Real-time Transport Protocol (RTP), which in
turn uses UDP, which in turn uses IP, the resulting audio packet length will be 66 octets
of header + audio data length (Table 1).
Next, we compute the size of the audio payload. This depends on the following coder
characteristics:
- Frame size (seconds per frame).
- Frames per packet.
- Packet redundancy.
- Bit-rate.
- Statistical savings due to VAD (voice activity detector).
As Example 1 shows (see sidebar), one IP channel using the G723.1 coder requires 24
Kbps. Enabling VAD significantly improves the bandwidth usage in Example 2 (see sidebar).
In these examples, there is a 90 ms (30 ms x 3 frames/packet = 90 ms) delay, since the
audio is packetized and shipped to the destination. If one frame per packet is used,
latency is reduced to about 30 ms. The tradeoff is three times as many packets being sent,
increasing bandwidth usage. Other factors not discussed here also affect bandwidth (e.g.,
redundant packets used to compensate for lost packets).
As the channel density increases, more packet collisions occur. Therefore, it
isn’t possible to scale linearly the number of supported channels based on available
bandwidth of LANs alone. More importantly, you also need to consider the available
bandwidth of the WAN, which is typically less than that of LANs. If a gateway application
is designed properly and underlying hardware supports multiple coders, the application can
use a higher bit-rate coder (better quality) during light data network traffic and switch
to a low bit-rate coder when the network becomes moderately congested. (If there is too
much data network congestion, the gateway application should place PSTN channels out of
service or reroute PSTN calls over the PSTN network.) The switching of coders is also
restricted by the coder capabilities of the destination gateway.
SNMP/Remote Administration And Configuration
Remote administration of VoIP gateways should be considered a key feature if you have many
gateways in your network. It is desirable for the system administrator to know when there
are PSTN problems and data network problems. For example, a T1 or E1 line may experience
alarms. During this period, the gateway will not be able to make PSTN calls. Similarly the
data network (IP) side has its own set of problems, such as a crashed router or congested
network. If a critical-path router has crashed, the gateway cannot make/accept any IP
calls; therefore, it should not accept/make any PSTN calls. If there is a congested
network, the quality of service degrades due to increased latency/reduced bandwidth. In
order to reduce downtime, the system administrator needs to be notified of any problem as
quickly as possible.
Simple Network Management Protocol (SNMP) is one of the most widely used network
management tools available. If a gateway application exports application-specific metrics
through SNMP, then SNMP management software can be used to monitor the status of all
gateways in the network. For example, if a PSTN alarm is pending, an SNMP trap can be sent
to the monitoring station to notify the system administrator of the alarm. Other devices
in the network (e.g., routers) can also send traps and update their own statistics that
can be monitored by the SNMP management software. Therefore, the system administrator can
monitor the whole network using one tool as opposed to using proprietary tools for
specific devices in the network.
Scalability
With faster DSPs coming to market, the channel density per gateway is increasing. Will
your gateway be able to take advantage of future technology advancements? Another area to
consider is how your gateway is affected by the ongoing evolution of the various
standards. Will your gateway need to be replaced once a new standard is adopted? Will it
remain interoperable? Will it be able to benefit from standards improvements?
Summary
In this article we pointed out the many features that make up an Internet telephony
gateway and raised some questions to ask vendors about their products. We cannot
over-emphasize the need for the gateway buyer to first determine present and future
requirements before making a gateway selection, as well as to keep in mind the importance
of performance, maintenance, and scalability.
Jitendra Shekhawat is a technical specialist, Dialogic Professional Services, and
Patrick Noon is an applications consultant, Dialogic Professional Services. Dialogic
Corporation is a manufacturer of open, high-performance, standards-based
telecommunications and computer telephony components. For more information, please visit
their Web site at www.dialogic.com
|
Internet Telephony Magazine
Click here to read latest issue
CUSTOMER 
Cloud Computing Magazine
Click here to read latest issue
IoT EVOLUTION MAGAZINE
