Automation of Call Setup in IP Telephony for Tests and Measurements

APPENDIX B
AUTOMATION OF CALL SETUP IN
IP TELEPHONY FOR TESTS AND
MEASUREMENTS1
In IP telephony, a call is usually established in multiple stages. In the first stage,
an ingress or call-originating IP-PSTN GW is accessed. This is followed by a
PIN-based caller authentication. Finally, the destination telephone number is
entered. If the GWs have enough digital signal processing (DSP) channels and
processing capacity, and the backbone (transport) network can support one
T1 CAS port’s worth of calls, we should be able to start 24 voice connection
attempts simultaneously. The call-originating GW should be able to process all
24 connection requests. However, it appears that most of the currently avail-
able IP-PSTN GWs cannot handle all 24 connection requests simultaneously.
Therefore, it is necessary to develop a method to determine the number of calls
that can be started simultaneously. It is also necessary to determine the inter-
call-burst time gap (in milliseconds or seconds) so that all 24 calls will be pro-
cessed using the existing hardware and software configuration and capacity
of the GW. This appendix describes techniques used to perform both of the
above functions. They are implemented using Hammer’ HVB language [1]
(www.hammer.com) for testing some commercially available IP telephony
GWs.
INTRODUCTION
The emerging IP telephony GWs for enterprise networking applications usually
support (a) one to four T1 ports per line card for interfacing to the PBX or
PSTN network and (b) one or two auto-sensing 10/100 BT Ethernet ports for
1 The ideas and viewpoints presented here belong solely to Bhumip Khasnabish, Massachusetts,
USA.
152
interfacing to the IP network via a LAN. One possible configuration for sup-
porting and testing black phone to black phone voice calls over an IP network
is shown in Figure B-1. Generic information on computer telephony testing

can be found in Reference 2. Note that a voice call originating from a PBX
or PSTN network is considered to be the one from a black phone. Figure B-1
also shows where and how (i.e., using what types of links) various kinds of
test equipment are connected to support di¤erent types of tests and measure-
ments. A detailed description of the testbed can be found in Appendix A and
Chapter 5.
The actual number of voice channels that can be used for voice conversa-
tion depends on the total number of DSP channels available in the GW. For
example, if 16 DSP channels are supported per remote access service (RAS)
card, a total of six (¼ 96/16) such cards would be needed to support the four
T1 ports or 4 Â 24 ¼ 96 voice conversations. Alternatively, if 24 DSP channels
are supported per RAS card, a total of four (¼ 96/24) such cards would be
needed to support the four T1 ports or 4 Â 24 ¼ 96 voice conversations.
Now, assuming that we have enough DSP channels and processing capacity
in the GW, and that backbone (transport) capacity is available to support one
T1 CAS (or ISDN PRI) port’s worth of voice conversation, we should be able
to start 24 (or 23 for ISDN PRI) voice connection attempts simultaneously.
The ingress (or call-originating) GW should be able to process all 24 connec-
tion requests. However, it appears that most of the first-generation IP-PSTN
GWs cannot handle all 24 connection requests simultaneously. It is there-
fore necessary to develop a method to control the number of calls started
simultaneously. At the same time, it is also possible to determine the amount
Figure B-1 A simple testbed for measuring the call setup performance of IP-PSTN
GWs. E, Ethernet link; T1, CAS or PRI link; BRI, basic rate interface links. NTS stands
for network time server; it provides timing information (clock) to the IP domain net-
work elements such as IP-PSTN GWs, GK, and NIST-Net, and if needed, it can derive
clocking information from a GPS receiver as well. A detailed description of the testbed
is presented in Chapter 5.
INTRODUCTION
153

of intercall-burst time gap (in milliseconds) needed so that all 24 calls will be
processed with the existing hardware and software configuration and capacity
of the GW.
A set of HVB [1] language-based scripts that can perform both of the above
functions is presented in this appendix. The proposed technique and the results
obtained are discussed. Some concluding remarks are presented next. The
scripts for emulating the call-originating and call-terminating parties are also
presented.
THE PROPOSED TECHNIQUE
In this section, we first present a simple example, followed by a generic
description of the proposed technique in the form of flowcharts. Next, another
example is discussed. Implementations using HVB are then presented.
A Simple Example
As mentioned earlier, with one set of T1 connection from the PSTN network,
the ingress IP-PSTN GW should be able to support gracefully a maximum
of 24 incoming call requests. However, because of limited DSP resources, very
often most of the call attempts fail. To solve this problem, a precall wait can
be added. The precall wait determines the amount of time the call-originating
script will wait before actually making a connection attempt over a selected
channel.
In this example, only one call setup request is in progress at any point in time,
and a precall wait time of 1 sec is used.
Let us define a parameter called ‘‘waitTick’’ which controls the intercall time
gap or precall waiting time, called ‘‘waitTime.’’ In this simple example, only
one call is started at a time, and a 1-sec intercall gap is added. In case of one
T1, we have 24 channels to start the calls or connection requests. The call in the
first channel starts at the same time that the script starts running on the chan-
nel, the call in channel 2 starts 1 sec after the script starts running, the call in
channel 3 starts 2 sec after the script starts running, the call in channel 4 starts 3
sec after the script starts running, the call in channel 24 starts 23 sec after the

time the script starts running in that channel, and so on. Therefore, the staging
of calls is as shown in Figure B-2. An implementation of this example using
HVB is shown in Figure B-3. In this example, the script that is making an
outgoing call is running on channel 1 [indicated by the parameter chanId( )],
and the script that will be receiving that call is running on channel 25, as
indicated by the parameter ‘‘sendID.’’ This depends on the system configura-
tion and can be easily controlled.
Once the ‘‘placeCall’’ event has occurred on a channel, for one-stage dialing
a ring tone would be expected from the called party’s telephone. For multistage
dialing, a dial tone or any specific predesigned tone or set of tones would be
154
AUTOMATION OF CALL SETUP IN IP TELEPHONY FOR TESTS
heard at the calling party’s telephone, and the calling party can then proceed to
the next stage of dialing.
Description of the Technique
The proposed technique consists of the following three major procedures.

Determining the maximum number of simultaneous incoming call requests
that an ingress GW can handle so that a connection setup is allowed and a
bidirectional conversation can proceed smoothly;
Figure B-2 Multistage call setup in IP telephony. One call setup request is in progress
at any point in time. The intercall-burst (burst size ¼ 1) time gap is 1 sec.
waitTick ¼ 1
sendID ¼ chanId( ) þ 24
’***---- For dialing into a Hammer channel use the following ***
dialnumber ¼ "655620" þ str(sendID) þ "#"
call startProtocol (HT_PROTO_WNK0,,)
waitTime ¼ (sendID-25)* waitTick
’***---- Use HT_SECONDS for sec. level wait, HT_MILLISECONDS for
millisec level wait

pause waitTime, HT_SECONDS
logmsg ") Pre-Call Wait is " & waitTime & " sec", HT_LOG_DEBUG
’***---- Enter the called party’s number ***
logMsg ") Placing call LU-GW4 B-to-A", HT_LOG_DEBUG
set event ¼ placeCall (dialnumber,)
Figure B-3 A simple example of adding a precall waiting time of 1 sec between each
call.
THE PROPOSED TECHNIQUE
155

Determining the intercall-burst time gap, which may vary from hundreds
of milliseconds to a few seconds, depending on the GW and GK soft-
ware, hardware, and processing capacity of the DSP modules of the GWs;
and

Developing a script or suite for determining the number of stages for set-
ting up a prespecified number of calls in multiple stages. For example, if a
GW can handle only four simultaneous incoming call requests, one would
need six (¼ 24/4) stages to set up 24 incoming call requests with a reason-
able amount of intercall-burst time gap.
Step 1: In this step, the objective is to determine the maximum number of
calls that can be started simultaneously so that the call attempts are
successful. For one T1 connection between the PSTN network and
the ingress/egress GW, it is possible to start the calls on all 24 channels
of a T1 line of the Hammer tester [1,2] at the same time. Then one
can visually monitor the status of the call requests in the Hammer
tester’s channel monitor. Usually, successful calls or connections are
indicated by a green color and failed connections are indicated by red.
If the connection requests are successful on all 24 channels, the ingress
GW is capable of handling 24 simultaneous connection establishment

requests. If not, one can either start with (24 À 1) or 23 calls, then
with (24 À 2) or 22 calls, and so on until a point is reached at which
all the connection attempts are successful. Alternatively, one can start
with only one connection request, then increase it to two, three, four,
and so on, and monitor the status of the connection requests in Ham-
mer’s monitor window to determine the maximum number (e.g., n
1
)of
calls that can be started simultaneously resulting in successful con-
nections. A flowchart describing various phases of step 1 is presented in
Figure B-4.
Step 2: Once step 1 is completed, one must determine experimentally the
intercall-burst interval that allows establishment of connections on all 24
channels for one set of T1 connection to the IP-PSTN GWs from the
Hammer tester. Our experiments show that we can start with 1 sec of
intercall-burst time gap, and depending on the number of stages involved
in call setup, we may need to increase it to a few seconds or decrease it to
hundreds of milliseconds.
Step 3: The objective here is to utilize the results obtained in steps 1 and 2 in
order to stagger the calls or connection requests so that the call attempts
are successful on all 24 channels. If multiple (say m) T1 links are available
from the PSTN network to the ingress GW, an attempt should be made
to make successful calls on all (m  24) channels. Note that the value of n
1
is determined in step 1 using the algorithm presented in Figure B-4. The
value of the intercall-burst interval is determined in step 2. Figure B-5
presents various phases of step 3 in a flowchart.
156
AUTOMATION OF CALL SETUP IN IP TELEPHONY FOR TESTS
Another Example

In this example, attempts are made to start multiple calls simultaneously with
an empirically determined size of the call bursts. Although it is possible to
implement a nonuniform distribution of bursts, for the sake of simplicity we
use uniform call bursts here.
Let us set the size of the call burst that represents the number of calls to start
at the same time—that is, the parameter ‘‘no_of_simult_calls’’—to 4. The
intercall-burst interval, waitTick, is set to 3 sec. With this combination of
no_of_simult_calls and waitTick, one would need six [¼ 24/4] stages and 15
[¼ 3 Â ((24/4) À 1)] sec to start all 24 calls. If all of the calls are made and the
call setup time is 5 sec, then successful establishment of all the connections
Figure B-4 Determination of the number of calls that can be started simultaneously so
that successful connections are established to the called telephones.
THE PROPOSED TECHNIQUE
157