IP Telephony Performance Evaluation and Simulation

Virginia Polytechnic Institute and State University

Bradley Department of Electrical and Computer Engineering
Mingwei Chen, Ming Luo, Jinggang Wang

Abstract
IP telephony presents some big advantages over traditional circuit-switched telephony especially
in the sense of increased utilization of expensive backbones and significantly reduced cost. However, in
order to win the competition, IP telephony must provide the same quality of voice service as the
traditional telephony, which has been proven as a major challenge. In todays VoIP market, multiple
vendors have developed different IP telephony products based on some well-known IP telephony
Standards such as ITU-T H.323 and IETF Session Initiation Protocol (SIP). In Part I of this paper, we
present some metrics to help evaluate IP Telephony Performance, discuss a new architecture proposed by
Pawan and etc.[1], Distributed Open Signaling Architecture (DOSA), as an enhancement to H.323 and
SIP. Then in Part II, we conduct a simulation experiment to demonstrate the backbone-scheduling
requirements for this robust IP telephony architecture.

Part I: Critical Paper Review and Summary

Introduction
High-quality telephony service must meet the stringent bounds on end-to-end voice signal delay,
jitter and loss. This requires adequate capacity allocation along the end-to-end path for a voice flow. This
requirement is met quite well in traditional telephony in PSTN by using per-flow hop-by-hop signaling
and providing service guarantee with a temporary dedicated circuit. In IP Telephony, however, in order to
improve the system utilization efficiency, no dedicated circuit will be associated with each voice flow.
Instead, all voice flows are statistically multiplexed together with all other data and video traffics in every
hop of Internet. This makes a VoIP call much cheaper than a PSTN phone call.
However, how to provide comparable voice service quality as the PSTN phone poses a major
challenge for IP Telephony designer. Since originally IP provides only best-effort service for all traffics,
unavoidably, this makes the end-to-end delay, jitter, and packet loss for voice traffic vary dramatically
between different Internet traffic situations. In order to solve these problems, tremendous research effort
has been given to VoIP architecture design, which also gave the birth of two well-known IP telephony
Standards: H.323 and SIP.
Although IP Telephony has come to peoples life for several years, there is still much to be
improved. Even in the two IP telephony standards, no specific and optimized end-to-end Quality of
Service (QoS) Management Module has been finalized and implemented. In this paper, we will discuss a
new architecture proposed by Pawan and etc. [1], Distributed Open Signaling Architecture (DOSA), as an
enhancement to current IP standards. Before the discussion of detailed architecture, lets see how IP
telephony performance is measured.

Performance Measure Metrics

1.End-to-END Delay Metrics.
ITU-T has carried out an extensive testing over three decades, and then gave the
Recommendation G.114 to provide guidelines on the tolerable delay for a normal telephone conversation.
According to the recommendation, the maximum one-way delay acceptable for most applications is
150ms.
We can use a delay budget to allocate this 150-ms one-way delay limit among several different
sources. The biggest delay component is backbone propagation delay. The worst-case one-way delay in

the continental United States has been measured at 95ms. This leaves a remaining delay budget of only
55ms in one-way for all other sources. As a general example, we can allocate 10ms to the speech coder,
10ms to speech enhancement and silence suppression, and 5 ms to processing, propagation, and
interleaving in the local area network, and 15 ms to play-out buffer at the receiver. Finally, we have 15 ms
budget for jitter tolerate during the whole transit. Among this 15 ms, 5ms can be given to the local area
network, and this leaves 10ms for queuing delay in the backbone network.
2. Packet Loss Metrics.
Packet Loss requirement for encoded speech is typically 1 percent or less. Although we can use
loss-concealment algorithms to reproduce intelligible speech even with higher loss rates, this is not
desired if we want it work as a circuit-switched replacement.
3. Post-Dial Delay Metrics.
We want the delay between the user dialing the last digit and receiving positive confirmation
from the network not to be perceptibly different from post-dial delay in the circuit-switched telephony.
4. Post-Pickup Delay Metrics.
We want the delay between a user picking up a ringing phone and the voice path being cut
through to be short enough that the initial hello is not clipped.

Distributed Open Signaling Architecture (DOSA)

Signaling architecture and resource management framework are two important components of the
whole IP telephony system. Since user expectations of quality impose stringent requirements on both
network and signaling performance, we believe that network-layer QoS guarantee is essential to robust IP
telephony service. As a result, the network must support resource reservations and admission control, and
the signaling architecture must ensure the authorization and correct charge for the resource usage.
Figure 1 shows all the key components in the DOSA architecture. From this diagram we can see
there are totally four key components in the system: Customer Premises Equipment (CPE), Edge
Router, Gate Controller, and PSTN Gateway. Every conventional telephone or multimedia PC accesses a
local access network through a Customer Premises Equipment, which may be a multimedia terminal
adaptor. Every local access network accesses a Managed IP backbone through an Edge Router. An
important management component in IP telephony system is the Gate Controller. If an IP telephone wants
to talk to a PSTN telephone, a PSTN Gateway can provide the interface between the IP network and
PSTN.

Gate
Controller

pc

Gate
Controller

LAN

CPE

telephone

pc
LAN

ER

Managed IP
Backbone

ER

CPE
telephone

PSTN
Gateway

telephone
PSTN

Figure 1: Distributed Open Signaling Architecture [1]

For robust telephony service, a service provider must manage access to the network-layer
resources, and the Edge Routers are in charge of Admission Control at the boundary to the backbone
network. ERs implement a function called a gate to control the access. Once a gate is opened, the ER
starts to provide enhanced QoS service. However, before opening a gate, the ER requires authorization

from a Gate Controller on a call-by-call basis, which ensure the user has a valid account in the Gate
Controller.
Gate Controllers implement a set of service-specific control functions such as authentication and
authorization, number translation and call routing, admission policy control, signaling and service feature
support. The Gate Controller is designed as a stateless transaction server, which makes it efficient, highly
scalable, and more reliable.

Signaling Architecture Comparison with H.323 and SIP

There is no big difference about key component members and associated functions between the
DOSA architecture and the architectures defined by H.323 and SIP standards. Actually they are quite
similar in basic architecture design.
The key distinction between DOSA and H.323, SIP is related to signaling architecture. In H.323
(Version 3) [2] and SIP [3] standard, call signaling and resource management are two isolated procedures.
That is, call signaling accomplishes first, and only after the call connection is established, which means
the phone rings and the called party picks up the phone, can the resource reservation procedure begins.
But in DOSA architecture, there is explicit coordination between call signaling and resource management.
That is, the backbone resource reservation accomplishes before the phone rings, which means the
resource reservation is done during call signaling. In DOSA, the resource reservation is partitioned into
two separate phases: reserve and commit. At the end of reserve phase, backbone resources are reserved
and allocated but not yet available to the CPE, which help reduce Post-Pickup Delay. At the end of
commit stage when the called party is rung and answers, resource are committed and made available to
CPE and the usage charging begins.
The call signaling architecture in DOSA has the advantage to provide the following critical
functions: 1, Network resources are available end to end before ringing; 2, Resource usage is properly
accounted for, that is, charging occurs only after the called party picks up. The drawback of this
architecture, however, may also relate to this signaling architecture. We think, one may criticize that this
method will waste some network resources and increase Internet traffic. Because some percentage of
phone call cannot establish connection when the called party does not pick up the phone, and usually it
takes time for the phone to ring several times before people give up, since the resource reservation has
been done before the ring, it seems a waste. Especially when we take the soft state property of RSVP into
account, it increases more Internet traffic by keeping sending PATH and RESV messages during
refreshment of RSVP.

Backbone Resource Management

In DOSA architecture, admission control and traffic scheduling are important to meet the QoS
requirement for voice flows. Admission control can ensure end-to-end adequate capacity for each
admitted voice call. Packet scheduling can ensure bounded end-to-end queuing delay for voice flows
when multiple kinds of traffic data compete for a single port.
One problem is related to scalability of the QoS mechanism. When hundreds of thousands of
voice flows are active in the backbone, its not scalable to implement per-flow queuing and scheduling at
all. DOSA architecture does not require per-flow signaling and scheduling. It uses per-flow hop-by-hop
signaling in the access network and per-pipe (aggregation of flows) hop-by-hop in the backbone network.
Pawan Goyal and etc have shown that handling all voice packets in a single FIFO queue can meet
the stringent delay requirements under the situation of weighed fair queuing (WFQ) with a sufficiently
large weight assigned to the voice queue. As discussed in the above performance metrics part, the
stringent end-to-end queuing delay is 10ms. In Part II of this paper, we will conduct a simplified
simulation experiment to demonstrate this idea works fine.

Part II: Backbone Scheduling Simulation Experiment

Objective:
In this simulation experiment, we will demonstrate the backbone scheduling mechanism in
DOSA architecture can meet the stringent end-to-end queuing delay requirement, that is, less than 10ms,
under usually Internet situations, say, hop number is within some reasonable range.
Simulation Model Construction and Parameterization:
DOSA architecture backbone resource management mechanism makes two assumptions: 1, all
voice flows are aggregated into a single FIFO queue; 2, Weighted Fair Queuing is used to partition
bandwidth between the voice queue and other classes of traffic, and the weight for voice queue should be
efficiently large.
In order to simulate a backbone network that meets the above two assumptions, we choose the
topology as shown in Fig. 2 to study. In this topology, we build a voice source node, a voice destination
node, a data source node, a data destination node, two edge routers, and several backbone routers. Since
the end-to-end queuing delay is related to hops, we need to get the simulation results for different
backbone router numbers.

Fig 2: Simulation Topology

All the source nodes and destination nodes are easy to build. Figure 3 illustrates a source node
model. We can configure it as a voice source or a data source just by setting src parameters. End-toEnd Delay is a performance metric, which is associated with every packet from its generation.

Fig.3: Source Node Model

Fig.4: Edge Router Model
Edge Router Model is illustrated in Fig 4. In this ingress Edge Router, two receiver models are
connected to a hub process model and then connect to a transmitter model. Egress Edge Router has the
same components except the order exchange of transmitters and receivers.

Backbone Routers are very important components in the whole topology because the queuing and
scheduling algorithms need to be implemented in the backbone routers. In order to accomplish WFQ
scheduling, we need the following state transition diagram as in Fig.5.

Fig 5: State Transition Diagram for Backbone Router Process

In the arrival state, we partition arrival traffic into 2 subqueues: one for voice, one for data. In
Svc_start state, we can set the service rate, which is an important factor determining the end-to-end
queuing delay. In Svc_compl state, we can set different weights for voice subquque and data subquque.
The corresponding C code for this function is shown as Fig. 6

Fig.6 C code for Weighted Fair Queuing Implementation

Simulation Experiments:
We run the simulation for different hops(1 hop and 10 hops), different weights(1,1.5,2,3) and
different Queue Service Time(range from 0.4ms to 10.8ms).
Voice Packet size 512bits, inter arrival time 0.008 second, Distribution: constant
Data Packet size 4096bits, inter arrival time 0.01 second, Distribution: exponential

Simulation time is 5 minutes, normally that is enough for our system to reach the stable state.
Figure 7 and Figure 8 shows the graph of End to End delay results.

Fig. 7 ETE Delay Weight=2 Hop=1 Queue Service

Time = 9.8ms (Top: Voice. Bottom: Data)

Fig. 8 ETE Delay Weight=2 Hop=10 Queue

Service Time = 1ms(Top: Voice. Bottom: Data)

Simulation Results:
We use end to end delay as performance metric. The result is shown in table 1 and table 2.
1 hop
Service Time(ms)
0.4
0.8
1.0
1.2
1.8
4.8
9.8
10.8

10 hops
Voice(ms)
0.61
1.17
1.20
1.34
1.85
3.96
4.23
4.05

Data(ms)
2.06
2.60
2.66
2.85
3.43
7.21
133.33
unstable

Voice(ms)
4.63
8.44
9.81
11.6
18.0
46.6
91.8
101.8

Data(ms)
9.40
12.2
14.0
16.0
21.7
52.2
228.0
unstable

Table 1. End to End delay on different Service Time and hops.(Weight=2)

E T E D e l a y v s S e r v i c e T i m e ( w e i g h t = 2 )

V o ice E T E ( 1 h o p )

Data ETE(1 hop)

V o ice E T E ( 1 0 h o p )

Data ETE(10 hop)

2 5 0

2 0 0

1 5 0

1 0 0

5 0

0
0

S e r v ic e

10

12

T im e ( m s )

Fig 9. End to End delay on different Service Time and hops.(Weight=2)

Service
Time(ms)
0.8
1.0
1.2

Weight = 1
Voice(ms)
9.45
10.7
12.4

Data(ms)
11.2
12.6
14.3

Weight = 1.5
Voice(ms)
9.02
10.2
12.1

Data(ms)
11.8
13.3
15.2

Weight = 2
Voice(ms)
8.44
9.81
11.6

Data(ms)
12.2
14.0
16.0

Weight=3
Voice(ms)
7.59
8.11
9.32

Data(ms)
14.3
16.4
18.7

Table 2. End to End Delay (in ms) on different Service Time and Weights(hops = 10)

From the results of simulation, we can see that if service time in the queue is too large, the system
becomes unstable. ETE delay of 10 hops is significantly larger than 1 hop ETE delay. But the ratio is not
10, which means there are some kind of delays in Edge Router and links. These delays are relatively small
in our simulation experiments. Fig 9 shows the plot of ETE delay on Table 1. We do not show some large
delays and unstable situations to gain a good scale.
The weight also affects performance greatly. Weight reflects the priority of the packets. For
example, weight=2 means voice packet got twice possibility to be serviced than the Data packets, if there
are packets in the subqueues. We notice that for small service time, the difference is not as big as large
service time. That is because under small service time the subqueues are not always has packets to be
serviced, while under large service time there are always packets in the subqueues ready to be serviced. In
our simulation, given a relatively large Queue Service Time, a large weight should be given to the voice
packet to ensure the queuing delay is less then 10ms.

Simulation Validation:
Our simulation results consistent with the analysis in the paper from Pawan and etc. [1]. First, we
can assign just one queue for all voice traffic to simplify backbone network signaling and scheduling
mechanisms and to make the architecture more scalable; Secondly, In order to make sure ETE Delay is
less than 10ms for 10 hops (probably the largest hop number in US Continent), we should assign a higher
priority to the voice packets than data packets.

Simulation Discussion:
In our simulation, we only tried WFQ scheduling algorithm. There may be other scheduling
algorithms we can use to schedule voice packets and data packets. In addition, due to the limited project
time, we didnt try more source traffic characteristics and more different backbone structures such as
more traffic flows go in and out of mid-routers.

Conclusions
After we finish all the reading, understanding, discussing, trying, modifying and summarization
work of this project, we feel we have gained a lot of knowledge about IP telephony architecture design,
performance measurement, traffic modeling, and backbone network simulation. First, in order to
understand this paper, we have read several documents about IP telephony and understood most of the
ideas; Secondly, in order to conduct the simulation experiment, we have read most of the help
documentation in OPNET software. At the same time, we reviewed and used almost all the skills in
project 1 and 2, and finally got the simulation model to work perfectly. According to our rough
estimation, the level of effort for each of us in this project is 2 times of that in project 1 and 2.

Acknowledgement
Our acknowledgement should be given to Dr. Midikiff, the diligent and knowledgeable course
instructor, for his insightful comments before we conducted the simulation experiments. Our original plan
was definitely too ambitious to finish in a course final project. We also want to show our
acknowledgement to Peng Li, one of our classmates in this class, for his suggestions in OPNET.

References:
[1] Pawan Goyal, Albert Greenberg, Charles R. Kalmanek, William T. Marshall, Partho Mishra, Doug
Nortz, and K.K.Ramakrishnan, Integration of Call Signaling and Resource Management for IP
Telephony, IEEE Transactions Network, May/June 1999.
[2] Thom, G..H.323: The Multimedia Communications Standard for Local Area Networks,IEEE
Communciation Magazine, 1996
[3] SIP Home Page http://www.cs.columbia.edu/~hgs/sip/
[4] OPNET 7.0 Documentation