This document proposes a design for a quality of service aware billing system for VoIP calls. The design aims to extract network traffic data and determine a billing rebate if the quality of service for a call falls below an acceptable level. The design incorporates elements such as call detection, network data extraction using protocols like RTCP and RTP, quality of service estimation using a modified E-model equation, and calculation of billing adjustments based on the estimated quality of service. A simulation of the quality of service calculation component shows it can accurately estimate quality comparable to existing algorithms. The proposed design extracts data using simple methods and minimizes billing data using compression techniques, while aiming to accurately determine quality of service.

1. QUALITY OF SERVICE AWARE TARIFF MODELS
FOR VOIP CALLS
School of Electrical & Information Engineering
University of the Witwatersrand
.
Neal Derman
0405238T
August 21, 2009

2. Abstract
Many telecommunications service providers are beginning to implement IP based so-
lutions for telecommunications. In order for IP based technologies to be competitive they
must provide quality of service guarantees which are acceptable to network users.
The purpose of this paper is to design a quality of service based billing system which
allows a user's tari to be reduced when they experience a lower than acceptable quality
of service for a given call. This system must extract quality of service data and record
billing information while having minimal impact on network performance.
A design is proposed for an entire quality of service billing system which incorporates
elements such as call detection, network data extraction, subjective quality of service
estimation and calculation of a billing rebate based on the quality of service experienced.
The quality of service calculation component of this design is simulated using realistic
network models and is shown to be comparable to existing quality of service estimation
algorithms.
The proposed design is able to accurately extract network trac data and determine
a billing rebate based on this data. The data is extracted using simple methods and the
billing data generated is minimized by the use of compression techniques. Some eciency
in the calculation of quality of service is sacri

3. ced in order to allow the estimated quality
of service to be determined as accurately as possible.
The accuracy of the quality of service measurements obtained by this design could be
further improved by using subjective quality of service measurements in order to calibrate
the quality of service estimation equations. The proposed design is also heavily reliant on
the assumption that the IP network on which it will be implemented is self contained and
fully accessible and this assumption should be reevaluated as a possible improvement to
future work.

4. Contents
1 INTRODUCTION 1
2 BACKGROUND AND EXISTING
SOLUTIONS 1
2.1 Assumptions and Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.2 Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.3 Trac Data Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.4 Synchronization of Measurements . . . . . . . . . . . . . . . . . . . . . . . 3
2.5 Existing Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 BILLING SYSTEM DESIGN 4
3.1 Design Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Design Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Calculation of QoS From Call Data . . . . . . . . . . . . . . . . . . . . . . 5
3.3.1 Trac Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3.2 The E-Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Derivation of Final QoS Algorithm . . . . . . . . . . . . . . . . . . . . . . 7
3.4.1 Signal to Noise Ration . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4.2 Simultaneous Impairment Factor . . . . . . . . . . . . . . . . . . . 8
3.4.3 Delay Impairment Factor . . . . . . . . . . . . . . . . . . . . . . . 8
3.4.4 Equipment Impairment Factor . . . . . . . . . . . . . . . . . . . . 9
3.4.5 Advantage Factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.6 Final Modi

5. ed E-model Equation . . . . . . . . . . . . . . . . . . . 10
3.5 Calculating MOS from R Factor . . . . . . . . . . . . . . . . . . . . . . . 10
3.6 Call Identi

6. cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.6.1 Session Initiation Protocol . . . . . . . . . . . . . . . . . . . . . . . 11
3.6.2 H.323 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.7 Measurement of Network Data . . . . . . . . . . . . . . . . . . . . . . . . 13
3.7.1 Data Extraction from RTCP . . . . . . . . . . . . . . . . . . . . . 13
3.7.2 Data Extraction from RTP . . . . . . . . . . . . . . . . . . . . . . 13
3.8 Data Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.9 Billing System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.10 Summary of the Role of Various Components of the System . . . . . . . . 16
3.10.1 Measurement Device . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.10.2 Consolidation Server . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.10.3 Billing Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4 CRITICAL ANALYSIS OF PROPOSED
SOLUTION 17
4.1 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1 Eect of Losses on R Factor for Various Codecs . . . . . . . . . . . 17
4.1.2 Eect of Delay on R Factor . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Analysis of Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Recommendations for Future Work . . . . . . . . . . . . . . . . . . . . . . 20
4.4 Social, Economic and Environmental Impact . . . . . . . . . . . . . . . . 21
5 CONCLUSION 22

7. List of Figures
1 A conceptual overview of the design for the proposed VoIP billing system 6
2 MOS for varying R factors . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Compression ratio for various amounts of data using gzip compression . . 15
4 Percentage rebate for various Mean Opinion Scores . . . . . . . . . . . . . 15
5 R factor comparison for G.711 with PLC using bursty packet losses . . . . 18
6 R factor comparison for G.729 using bursty packet losses . . . . . . . . . . 18
7 R factor comparison for G.723 using bursty packet losses . . . . . . . . . . 19
8 Idd with increasing mean delay . . . . . . . . . . . . . . . . . . . . . . . . 20

8. 1 INTRODUCTION
Many telecommunications providers are moving away from traditional PSTN networks
and are beginning to implement IP based solutions for telecommunications [1]. These
solutions allow service providers to consolidate their services into a single network which
will provide support for various multimedia applications [2]. For the new integrated
services networks to be able to compete with the existing PSTN network they must be
able to provide a level of quality of service guarantees which are acceptable to the users
of the network [2].
The goal of this report is to propose a proof of concept design for a Voice over IP (VoIP)
billing system which allows users to be billed appropriately in the event that their network
service provider is unable to deliver an appropriate level of service quality. In order for
this type of billing system to be implemented a method of non-intrusively extracting QoS
and converting this quality of service to tari must be designed, additionally the data
collected and recorded in order to allow billing should minimally interfere with normal
network performance.
This report begins in Section 2 by exploring the concept of quality of service mea-
surement and discusses many of the factors which are universal to all quality of service
measurement tools such as the synchronization of network data measurements. Some of
the existing quality of service measurement tools are also discussed brie
y.
Section 3 gives a top to bottom design of an entire billing system which meets the
criteria stipulated above. The proposed design covers the entire billing system from the
detection of VoIP calls all the way to the actual calculation of a billing rebate based on
the measured quality provided in a given call.
In Section 4 the QoS calculation aspect of the design is simulated and compared with
existing QoS measurement solutions so that the design can be critically analyzed. This
critical analysis yields suggestions for future work and improvements to overall design.
Finally the social, economic and environmental impact of the proposed design is discussed
before conclusions about the success of the design are drawn.
2 BACKGROUND AND EXISTING
SOLUTIONS
2.1 Assumptions and Constraints
As this design is a proof of concept of the technical aspects of developing a VoIP billing
system a number of assumptions were made in order to reduce the complexity of the
design so that the basic concept can be illustrated. The primary assumptions made are
the fact that the entire network of interest is fully controlled by the company implementing
the billing system and therefore network performance measurements can be taken at any
point in the network. This assumption makes it possible to measure the quality of service
of a call without requiring access to another company's network. A second assumption
is that all calls to be billed for are VoIP to VoIP calls. This means that separate billing
models need not be developed for dierent types of calls and therefore the billing model is
simpli

9. ed. Finally it is assumed that the billing system to be used is post pay and not pre
pay, this implies that the billing system need not be fully real time in terms of applying
any rebate for reduced quality of service during the call. The quality of service can be
1

10. calculated for all calls and stored until the customer is billed.
The primary constraint which applies to the design of the VoIP billing system is the
fact that the billing system must have a minimum impact on the performance of the net-
work. This results in a number of requirements for the system. Firstly the performance
information must be extracted quickly without compromising the speed of the transmis-
sion. Secondly a minimal amount of trac data must be generated and transmitted by
the billing system in order to ensure that the billing system does not contribute excessive
amounts of network trac.
2.2 Quality of Service
Quality of service (QoS) is a representation of the quality which is provided by a network
provider with respect to whatever services they are oering to a user or organization.
Quality of service can be broadly divided into two main categories, objective and subjec-
tive QoS [3][4].
Objective quality of service is quality of service which can be directly measured from
network performance. It is determined from factors such as packet loss, jitter, delays etc.
and gives a quantitative measure of the quality of network trac in a network [4].
Subjective quality of service is the quality of a given service as perceived by the user
of that service [3][4]. For multimedia applications the perceived quality is the quality
which the user actually experiences. Therefore in order to develop a billing system which
accounts for quality of service the perceived or subjective quality of service must be
measured or approximated.
The subjective quality of service for a VoIP call could be measured by allowing each
user to rate their call at the completion of the call. However this type of system could
not be used for a billing system as the user could simply give all calls a lower rating in
order to decrease their bill. For audio applications such as VoIP a number of systems
exist which map objective quality of service measurements such as delay and packet loss
to approximations of the perceived quality which the user will experience [3][5][6]. In
order to map objective factors to subjective QoS a method of rating a given call must
be used. Many of the popular algorithms, such as the E Model and PESQ, which are
used to approximate subjective QoS, use what is known as a Mean Opinion Score (MOS)
[3][4][6][7].
In order to determine MOS test subjects give an audio signal a quality rating from
1 to 5, these ratings are then averaged over all of the subjects in order to determine the
MOS [3]. The MOS can be measured under dierent network trac conditions in order
to determine how various objective network trac factors aect the subjective QoS of an
audio signal transmitted over a network.
For this design a simple algorithm was developed which allows the mapping of network
trac data to MOS scores in real time.
2.3 Trac Data Measurement
There are two main methods for measuring network performance, active and passive
methods [4]. Active methods involve generating known network trac and transmitting
it on the network [4]. This allows the sent data to be compared with the received data
in order to determine how the network is performing at a given point in time. This type
of measurement system is not useful for a billing application as it does not provide real
2

11. time information about actual network trac. Passive systems involve the extraction of
network data from existing network trac in order to determine the network performance
[4]. This type of system is applicable to a billing system as it allows network performance
data to be extracted in real time from current network trac. This real time data can
then be used to approximate the audio QoS, via a MOS, as described above.
Passive measurements can be taken at various numbers of points on a network, speci

12. -
cally the measurements can be taken at a single point, at the endpoints of a trac stream
or at multiple points in the network [2][4]. Single point measurements are not an accurate
method of measuring network performance due to the fact that they require the generally
false assumption that single direction delays are simply half of the round trip delay [4].
Multiple point measurements provide an accurate method of measuring network perfor-
mance and also allow the location of causes of decreased QoS to be determined because
QoS can be measured between each measurement point [2][4]. End to end measurements
are sucient for determining the QoS of a given trac stream between those points [2][4].
For a billing application end to end measurements are sucient as the location of the
cause of QoS degradation is not relevant to the billing and distributed measurement over
multiple points requires higher overheads as more measurement devices are required and
more measurements are made.
For this design it was determined that end to end measurements are sucient in order
to provide accurate network performance data.
2.4 Synchronization of Measurements
In order for accurate network performance measurements to be taken using an end to
end measurement system the clocks at the measurement points must be accurately syn-
chronized so that delay can be correctly recorded [2][4][8]. Clock synchronization can be
achieved using a number of techniques.
Some techniques use a network protocol such as Network Time Protocol (NTP) to
synchronize the clocks at the measurement points with a central, accurate clock [2][4][8].
This method requires an extremely accurate algorithm and protocol for the transmission
of clock information across the network [8] and current algorithms such as NTP are not
suciently accurate for delay measurements in modern networks [4]. Due to the fact
that this method requires transmission of time information over the network a further
inaccuracy is introduced as network delays will aect the arrival of timing information
and induce further errors [2][4].
Alternatively clock data can be transmitted to the measurement points using a trans-
mission method which is independent of the network. This requires a device which has
an accurate, machine readable, clock which can be read by or integrated into the mea-
surement device [8]. Two popular methods of performing this type of synchronization are
radio and GPS [2][4][8][9]. Radio synchronization is deemed unreliable due to its suscep-
tibility to electromagnetic interference and the fact that synchronization is relatively slow
[8]. Accurate synchronization can be achieved by transmitting clock data using a GPS
connection [2][9].
In [10] Paxson argues that even a well synchronized clock is not sucient for accurate
network performance measurements due to the fact that the clock may still be unstable.
Sudden changes in the clocks of the measurement devices will result in large errors in delay
measurements. In order to ensure consistent accuracy of delay measurements algorithms
such as those described in [10] can be used in order to detect sudden clock changes and
3

13. correct them.
It was decided that the measurement devices to be used for the billing system described
in this report should each include a GPS receiver for clock synchronization with a central
clock and that algorithms for correcting clock instability should be included in the software
of the measurement devices.
2.5 Existing Algorithms
A number of algorithms exist for determining the QoS of an audio signal. Described
below are some of the commonly used algorithms for determining QoS from network
performance.
Perceptual Evaluation of Speech Quality (PESQ) is a set of ITU-T standards which
are used to calculate perceived quality of service by sending a reference signal over a
network and comparing the received signal to the sent signal [7][11]. Due to the fact that
it requires comparison with a reference signal and is computationally intensive PESQ is
not suitable for real time applications and therefore is not suitable for a billing system [3].
In [3] the results of PESQ are replicated using a Genetic Programming approach which
ultimately results in a simple series of equations which can determine a PESQ-like MOS
score in real time.
The E-model is an ITU-T standard used for transmission planning [5]. The E-model
uses network trac parameters to determine a MOS as described above [5][6]. Essentially
the E-model is a series of equations used to

14. nd a R factor which can be used to

15. nd
a MOS which approximates subjective quality based on the performance of the network
[5] and a number of other factors. The E-model uses simple equations and is based on
network trac factors and other objective and subjective measurements and can therefore
potentially be implemented in real time.
Single Sided Speech Quality Measure (3QSM) is another ITU-T standard for deter-
mining a subjective QoS score. 3QSM functions similarly to the E-model in the fact
that it calculates a subjective QoS score based on network trac data [7]. 3QSM is not
suited for a billing application as it does not predict the subjective quality as well as other
methods and because it is computationally intensive [7].
3 BILLING SYSTEM DESIGN
3.1 Design Approach
The overall design approach taken was essentially a systems approach. Initially the entire
billing and measurement system was considered and a basic design was determined. This
design incorporated basic features such as the type of measurements to be taken, the
location of these measurements and a basic idea of how these measurements would be
translated into a

16. nal billing scheme.
The basic design was then broken into smaller subsystems which could then be designed
in isolation in order to achieve the

17. nal goal of designing a QoS aware VoIP billing system.
The main subsystems which make up the overall design of the billing system are: the
method of extracting network data from a VoIP call, the algorithm for translating this
call data into a meaningful QoS score which can be used for billing and

18. nally the billing
4

19. system itself which is used to consolidate the QoS data in order to determine how a
customer should be billed for a given call.
3.2 Design Overview
Figure 1 shows a conceptual overview of the design for the proposed VoIP billing system.
Measurements are made at routers on the edges of the IP network which carries the VoIP
call. This provides an end to end measurement of the network performance experienced
on the IP network. These measurements are made by a black box measurement system
which could be a network device in its own right or could be a software application
running on a router or server. As described above the measurement systems will include
GPS synchronization technology and will implement algorithms to ensure that the clocks
of these devices remain stable and accurate. This design measures the end to end quality
of service between the routers on the edges of the network when a call is made. For this
measurement to be considered accurate the inherent assumption is made that the QoS
degradation experienced between the client computer and the router on the network edge
will be negligible when compared with the QoS loss on the IP network.
The data which is collected by the measurement devices is then transmitted to a
consolidation server. Although not depicted in the conceptual diagram this transmission
will occur over the IP network on which the VoIP calls occur. The data transmitted to the
consolidation server will be compressed in order to help minimize the amount of network
trac which is generated by the billing system. The consolidation server will use the data
it receives in order to calculate simple objective QoS metrics such as average delay, total
losses etc. The role of this server is discussed in greater detail later in this report.
Finally the QoS information calculated by the billing server is transmitted over the
IP network to the billing server. The billing server is used to keep track of all of the calls
which have been made and to record any rebates which must be awarded to a client due
to reduced QoS of a call. When the clients are billed a record of the billing information
can be generated from the information stored on the billing server.
3.3 Calculation of QoS From Call Data
As discussed above the user perceived QoS of a call can be approximated from objective
network trac parameters. Discussed below are the various trac parameters which can
have an eect on quality of service as well as a description of the algorithm which is used
in this design in order to approximate perceived quality of service.
3.3.1 Trac Parameters
The primary factors which aect the quality of transmitted voice data are [12][13]:
Packet loss
Jitter
Delay
Clipping Eects
Echo
Audio Encoding
5

20. Figure 1: A conceptual overview of the design for the proposed VoIP billing system
Packet loss aects the quality of the audio signal because it results in a loss of voice
data at the receiving client. The eects of packet loss on audio quality are dependent on
how the losses occur and on the codec being used for the encoding of the voice data [12][13].
Losses can occur as individual packet losses or, very often, as a burst of consecutive packets
which are lost together. The eects of individual packet losses can usually be corrected
for or reduced by using a Packet Loss Concealment (PLC) algorithm which attempts to
disguise the packet loss by inserting an appropriate sound in place of the lost audio data
[13]. Many codecs come with PLC algorithms included as part of the codec [13].
Jitter is a measure of the variation in delay times of the packets in a stream due to non
constant delay factors, such as queuing delays at routers [14]. Jitter can result in packets
arriving out of order or with an extremely variable rate and can lead to large degradation
of audio quality [14]. By use of a protocol such as Real Time Protocol (RTP) which
provides packet numbers and timestamps jitter can essentially be converted to packet
losses and delays by use of a jitter buer which buers packets for a preset or variable
time period in order to remove jitter and discards packets which do not arrive withing the
time period [14][15].
In order to maintain acceptable levels of audio quality end to end delays should not
exceed 400ms [14] and should be in the order of 100 - 200ms [13][14]. End to end packet
loss encompassed all losses experienced in a given audio stream.
The audio encoding has a large eect on the quality of service achieved for a number
of reasons. Firstly various audio encodings have dierent levels of compression, this
both directly aects the quality of the audio being transmitted and also weights the
importance of packet losses [13]. Encoding techniques with higher levels of compression
will generate packets which contain more audio data per packet, this means that the higher
the compression the larger an eect packet loss will have on audio quality. Audio encoding
also aects quality because dierent encodings use dierent techniques for dealing with
lost and out of order packets as described above.
6

21. Clipping (due to audio detection devices which start recording when a sound is played
and stop when the sound ends [15]) and echo (due to speaker volume and re
ection of
signals [13]) are extremely dicult to determine from measurements of network trac
and are therefore not considered in this proof of concept design.
The

22. nal algorithm implemented for QoS calculation is based on the E-model and uses
measurements of packet loss, delay and audio encoding in order to estimate a perceived
QoS.
3.3.2 The E-Model
As discussed above the E-model is an ITU-T standard used for transmission planning
and real time network quality analysis [5][12]. The E-model attempts to approximate the
audio quality experienced by a client by taking into account a number of psychological
factors[5]. According to [5] the psychological factors considered in the E-model can be
considered to be additive and the basic equation of the E-model is given by Equation 1
[5]. Equation 1 gives R, which is the rating factor for the transmission in question [5]
and is representative of the total psychological opinion of the quality of a given audio
transmission.
R = Ro Is Id Ie + A (1)
Each term of the E-model equation is described brie
y below, these de

23. nitions are
those given in [5].
Ro - The basic signal to noise ratio for the transmission
Is - The simultaneous impairment factor, the sum of all impairments which may
occur simultaneously with the transmission
Id - The delay impairment factor, the sum of all impairments due to delay
Ie - The equipment impairment factor, the sum of all equipment impairments, based
on MOS scores and network performance factors
A - The advantage factor, a measure of the advantages of receiving the audio trans-
mission despite its quality
3.4 Derivation of Final QoS Algorithm
The

24. nal algorithm developed for the measurement of QoS in this design is an imple-
mentation of the E-model with certain parameters assumed to be at their default values.
As stated in the Trac Parameters section above the factors which contribute to QoS
which cannot be directly measured from network trac are not considered in this design.
Therefore the only E-model factors which are of interest are those directly related to net-
work trac parameters. The factors which are not related to network trac are assumed
to have their default values as described in [5]. Additionally the equipment impairment
factor is calculated using the equations found in [12] which allow recency and the time of
packet loss to be included in the algorithm.
7

25. 3.4.1 Signal to Noise Ration
The signal to noise ratio for the E-model is given by Equation 2 where SLR is the
Sending Loudness Rating(a measure of the loudness of the audio signal sent through the
microphone by the sender) and No is the power addition of background and circuit noise
sources [5].
Ro = 15 1:5(SLR + No) (2)
Because the sending loudness and the circuit and background noise cannot be extracted
from the network trac detected by the measurement device used in this design the value
of Ro is set to it's default value of 94.769 [5]
3.4.2 Simultaneous Impairment Factor
The simultaneous impairment factor is given by Equation 3 [5]. Iolr gives the impairment
due to too low Output Loudness Rating, Ist gives the impairment due to non-optimum
side tones and Iq gives the impairment due to quantizing distortion [5]. None of these
factors can be directly measured from network trac and Is is therefore assumed to have
its default values for all of it's components. The

26. nal default value of Is can be shown
to be 0.44018 by substituting the default values in [5] into the equations for each of its
components.
Is = Iolr + Ist + Iq (3)
3.4.3 Delay Impairment Factor
The equation for delay impairment is given by Equation 4 [5]. In this equation Idte and Idle
give talker and listener echoes respectively [5]. As above these values cannot be measured
directly from network data and are set to their default values. The default values for Idte
is 0 and the default value for Idle can be shown to be 0.14905 [5].
Id = Idte + Idle + Idd (4)
Idd is de

27. ned as the impairment due to an absolute delay (Ta) [5]. When Ta is longer
than 100ms Idd is given by Equation 5, where X is given by Equation 6 [5]. When Ta is
less than 100ms Idd is 0 [5]. This means that absolute delay has no eect on QoS when
it is less than 100ms which is in line with the statement in [14] which says that absolute
end to end delays of less than 150ms are imperceptible to humans.
(
(1 + X6) 1
Idd = 25
6 3
1 +
hX
3
i6
1
6 + 2
)
(5)
X = log2
Ta
100
(6)
8

28. 3.4.4 Equipment Impairment Factor
The equipment impairment factor represents the eect of network equipment on the qual-
ity of service of a call [5][12]. The eect of dierent network conditions on this factor are
determined by using MOS [5]. In [12] Clark provides a method for calculating Ie which
takes into account the types of loss conditions being experienced on the network. Clark
makes use of a Markov model which de

29. nes two main network loss conditions bursty
and gap. Bursty conditions occur when the network is experiencing a high number of
losses whereas gap conditions occur when losses are infrequent (here the term gap refers
to gaps between packet losses) [12].
In the Markov model a network can move between the bursty and gap states with
various probabilities for dierent kinds of movement between the states [12]. In order
to determine the average equipment impairment factor for the network stream the im-
pairment factor when moving between bursty and gap conditions must be calculated [12].
Equation 7 and Equation 8 give the the quality level for burst to gap and gap to burst
movements respectively [12]. The time factor t1 is 5s and the time factor t2 is 15s [12]. In
these equations b and g are the length of a given burst or gap state in seconds [12]. These
equations have an exponential form as the perceived quality of service for a given network
state decays from a bursty state into a gap state and vice versa [12], for example the
network becomes slowly less and less bursty over time as it becomes more gap like and
the users perception follows this trend.
I1 = Ieb (Ieg I2)e
b
t1 (7)
I2 = Ieg (I1 Ieg)e
g
t2 (8)
In Equation 7 and Equation 8 above the equipment impairment values for burst(Ieb)
and gap(Ieg) conditions are used. Each of these factors is dependent on the losses, delay
variation and codec used as shown in Equation 9 and Equation 10 which are taken from
[12]. As discussed above the assumption that jitter buers are used means that the eect
of delay variation can be assumed to be 0 for these equations. The impairment values for
codecs are constants which are given by Clark in [12].
Ieg = Ieg(loss) + Ie(DV ) + Ie(codec) (9)
Ieb = Ieb(loss) + Ib(DV ) + Ib(codec) (10)
From Equation 7 and Equation 8 Clark derives an average equipment impairment
factor for an audio stream, this is given by Equation 11 [12].
Ie(average) =
(bIeb + gIeg t1(Ieb I2)(1 e
b
t1 ) + t2(I1 Ieg)(1 e
g
t2 ))
(b + g)
(11)
In order to take into account the fact that the point in a call at which quality loss
occurs aects the client's perception of the quality of that call a further adjustment is
made to the calculation of the equipment impairment factor. In order to adjust the
calculation of equipment impairment the assumption is made that any sudden increase
in equipment impairment factor will result in a loss of quality of service, the equipment
9

30. impairment factor will then exponentially decay back to the current average equipment
impairment factor [12]. This is done to take into account the psychological eect known
as recency which results in people weighting a decrease in quality of service towards the
end of a call more heavily than one which occurs earlier in a call [12]. The

31. nal result of
this assumption is Equation 12 which describes the behavior of the equipment impairment
factor after a sudden increase in impairment, in this equation t3 is 30, k is 0.7 and y is
the delay since the last bursty packet loss [12].
Ie(recency) = Ie(average) + (k(I1 Ie(average)))e
y
t3 (12)
3.4.5 Advantage Factor
Advantage factor represents the advantage gained by having access to the service being
provided [5]. The advantage factor increases if the service being provided is one which is
not easily provided or if there is some other reason that a loss of QoS could be tolerated
or expected for this service. In [5] example advantage factors are given as a guideline:
Conventional telecommunications are given an advantage factor of 0 whereas providing
telecommunications services in hard to reach locations is given an advantage factor of 20.
For this design the advantage factor was taken as being 0 because this design is purely
concerned with a proof of concept VoIP system which operates within an individual IP
network.
3.4.6 Final Modi

32. ed E-model Equation
After all of the simplifying assumptions and additions made to the E-model, as described
above, a

33. nal equation for the calculation of R scores from network trac parameters is
derived. The

34. nal algorithm used is shown in Equation 13 where Ie and Idd are as de

35. ned
above. As Ie is dependent purely on losses and codec and Idd is dependent purely on
absolute network delay the goal of developing an equation for estimating audio QoS based
solely on factors which can be extracted directly from network trac has been achieved.
R = 93:4 Ie Idd (13)
3.5 Calculating MOS from R Factor
In order to standardize the results which are generated using Equation 13 so that they can
be compared to other QoS measurements the R factor scores generated must be converted
to MOS. The E-model provides an equation for converting R factor to MOS as shown in
Equation 14 through Equation 16 [5]. Figure 2 shows graphically how MOS varies with
R factor as per these equations.
ForR 0 : MOS = 1 (14)
For0 R 100 : MOS = 1 + 0:035R(R 60)(100 R)7:106 (15)
ForR 100 : MOS = 4:5 (16)
10

36. Figure 2: MOS for varying R factors
3.6 Call Identi

37. cation
In order to calculate the QoS of a VoIP call network data about the call must be measured
and extracted. In order to do this the call must

38. rst be detected. Once the call has been
identi

39. ed it must be monitored and information about the call must be recorded. This
detection process is performed by the measurement system depicted in Figure 1. The
design discussed in this report assumes that the protocol to be used for the actual call
transmission will be the RTP protocol. RTP was chosen as it provides mechanisms which
help to detect losses or delays in packets and because it is a widely used protocol for
transmission of multimedia data which is compatible with both H.323 and SIP [14].
Two common technologies used for VoIP call initiation are Session Initiation Protocol
(SIP) and the H.323 set of standards [14]. Due to the popularity of these two standards
the measurement device must be able to identify calls which are initiated using either
of these technologies. What follows is a description of how each of these technologies
initiates and maintains a call and how these calls can be detected.
3.6.1 Session Initiation Protocol
SIP is an application layer protocol which is used to establish a call over an IP network
and to negotiate the conditions of that call such as the encoding, port and protocols to
be used [14][16].
A SIP call is initiated when the caller sends an INVITE message to either the person
to be called (in the case of a known IP address) or to an SIP proxy server when the callee's
IP address is not known to the caller [14]. The INVITE message contains an identi

40. er
for the person who is being called, the IP address of the caller, the audio encoding which
11

41. will be used for the call and

42. nally the protocol and port which the caller will be using
for the VoIP call which will be established [14][16]. The IP address of the caller as well
as the port and protocol to be used is sent using an SDP packet [17].
The INVITE message is either received directly by the callee or is forwarded to the
callee by the SIP proxy server [14]. If the protocol and encoding are supported by the
callee the callee responds with a 200 OK message which contains the callee's IP address,
the encoding which will be used for data sent by the caller, the protocol to be used for
the call and the port number to which data should be addressed [14].
Once a call is established the same port and IP address are used for the caller and the
callee throughout the call [14] therefore the IP addresses and port numbers are sucient
to uniquely identify a particular VoIP call. The measurement device used will therefore
be required to detect both the INVITE and OK packets which are used to initiate a call.
From these packets the IP addresses and ports used for the RTP streams which contain
the call data must be extracted so that call data can be extracted from the RTP streams.
In order to do this the measurement device must be capable of decoding application layer
protocols such as SIP.
In order for billing to be performed correctly the measurement device must also be
capable of detecting the end of a call so that billing can be stopped at the correct time.
In order to end a call which is established using SIP an SIP BYE message must be
sent by either of the parties involved in the call [16]. The call is terminated when an OK
response is received after a BYE message. The measurement device will mark the end of
a call when a BYE message is responded to with an OK message or when the call times
out.
3.6.2 H.323
H.323 is another popular standard which is used for call initiation and management on IP
networks [14]. H.323, if used, de

43. nes a series of protocols which must be used for every
aspect of a multimedia call over an IP network [14]. H.323 speci

44. es that the H.245 protocol
be used as a control protocol for the logical setup of a VoIP call and that Q.931 signaling
must be used for the initial call setup and for determination of the H.245 addresses of the
parties involved in the call[14][18].
As H.245 is the protocol used to negotiate logical call parameters, such as the IP
addresses, RTCP and RTP ports of the clients which are involved in the call, it is the
H.245 messages which must be detected and read by the measurement device in order to
be able to detect and uniquely identify a call which is initiated using H.323 [18][19]. By
decoding any H.245 messages received at the measurement device calls can be identi

45. ed
and monitored, by using the RTP ports and IP addresses of the clients, in a similar way
as speci

46. ed for SIP above.
An H.245 message is also used to close the logical connections used for the media
streams between call participants. As with the SIP BYE message discussed above the
measurement device must be capable of detecting this message and appropriately marking
the end of a call.
12

47. 3.7 Measurement of Network Data
As discussed above the audio data will be encapsulated using the RTP protocol. RTP
encapsulates real time data which is to be transmitted and appends a header which records
the timestamp, sequence number and payload type which is being transmitted [1][14].
RTP is usually used with RTP Control Protocol (RTCP) [1][14]. RTCP packets are used
to provide statistical information about network performance and give an indication of
the fraction and number of packets lost and of the inter-arrival jitter of the packets [1][20].
In theory much of the data required for QoS calculation can be extracted from either RTP
or RTCP. In this section the merits of each of these methods is discussed.
For a VoIP call an RTP data stream is created for each direction of audio communica-
tions [14] and therefore two RTP or RTCP streams must be tracked in order to monitor
a VoIP call. As discussed in the section on the derivation of the QoS algorithm above
the information required from an RTP or RTCP stream, in order to determine the QoS
of that stream, is the delay, loss and codec.
3.7.1 Data Extraction from RTCP
RTCP provides statistical data to the application layer which gives an indication of the
number of packets lost, the jitter and the timestamps of the RTP stream [1][14] therefore
from an RTCP packet the delay and loss could be calculated. The only other factor
required for the determination of QoS using the design equation in this report is the
codec used. This data can be extracted from either the H.245 control messages in a
call using H.323 or from the INVITE and OK message interchange in the case of a call
using SIP, as described above. Extraction of QoS relevant data from RTCP can therefore
theoretically be easily achieved by simply decoding both the messages used to initiate the
call and the RTCP packets associated with the streams relevant to that call. The RTCP
packet streams can be identi

48. ed in a similar manner to the identi

49. cation of RTP streams
described above, the RTCP stream will use the same IP address as the RTP stream and
usually uses the RTP port number plus one [14].
There are, however, a number of problems with this approach when applied to a billing
model. Firstly the losses indicated by RTCP are just percentage losses for a given stream
and do not give an indication of whether these losses occurred as bursts or as individual
losses [14][20]. This information is not sucient for calculation of Ie (as described above)
which requires knowledge of where in a stream the losses occur. The second problem with
the use of RTCP is an issue of security. As RTCP does not carry the actual audio data
the RTCP packets can simply be blocked by the client sending the packets, the actual
RTCP packet can then be replaced with an RTCP packet which indicates a much lower
quality of service than the one being experienced in the call. This results in a fraudulent
increased rebate on the client's tari.
For these reasons it was decided that the call data should not be extracted from the
RTCP packets.
3.7.2 Data Extraction from RTP
RTP encapsulates multimedia data and appends an RTP header which includes a times-
tamp and sequence number to that data [1][14]. The sequence number in an RTP header
allows packet losses to be detected and also allows the location and type of losses being
experienced to be determined because a large number of successive packets lost represents
13

50. a burst type packet loss. In this way the loss detection achieved by reading RTP headers
at the measurement device is superior to the detection provided by reading RTCP pack-
ets. In order to determine delays the timestamp given in the RTP header could be used,
however this timestamp is dependent on the system clock of the client device and this
type of clock has already been deemed insuciently accurate in the section on synchro-
nization of measurements in this report. Instead for accurate delay data a timestamp will
be generated for each RTP packet at the measurement device (which uses GPS clock syn-
chronization) and this timestamp will be used for billing. The

51. nal piece of information
required for the QoS approximation algorithm is the codec which is used to encode the
audio transmission. This information can be extracted from two possible sources: this
data could be extracted from call initiation data as described in the section on RTCP or
this information can be extracted directly from the RTP header which includes a

52. eld for
payload type which gives the codec used for the audio encoding [14].
RTP does not suer from the spoo

53. ng problem which RTCP experiences due to the
fact that the information used in the RTP header is used for correct playout and for jitter
buering at the receiver [14], this means that RTP header information cannot be altered
without impairing the quality of the audio stream.
Extraction of network data from RTP headers was chosen as the preferred method due
to its accuracy for packet losses and due to the fact that it is less susceptible to spoo

54. ng
than RTCP.
3.8 Data Compression
In order to minimize the amount of data which is transmitted from the measurement
device to the consolidation server and from the consolidation server to the billing server a
compression algorithm is used. A simple simulation was performed in order to show the
eect of this type of compression. For this simulation numerical data (which is extremely
similar to the type of data which would be transmitted from the measurement device to the
consolidation in order to convey the timestamp, losses and encoding) was compressed using
the gzip library. Figure 3 shows the compression ratio ((compressed size)/(uncompressed
size)) for various amounts of data being compressed.
From this

55. gure it is clear that even large amounts of numerical data can be compressed
greatly (to within 1% of its original size) using simple compression methods. This implies
that the amount of billing data required to be sent over the IP network can be minimized
in order to ensure it does not introduce increased network quality reductions.
3.9 Billing System
The actual billing system which will be used is given in terms of rebates on customer
bills. This allows the system to be applied to any existing or future billing systems
without needing to know the details of that billing system. In [13] a MOS of greater than
4 is deemed Desirable therefore any call with a MOS of greater than 4 does not receive a
rebate. Similarly any MOS of less than 2.6 is not recommended [13] and for calls below
this quality a 100% rebate is given. Between these values the rebate is scaled linearly as
shown in Figure 4.
14

56. Figure 3: Compression ratio for various amounts of data using gzip compression
Figure 4: Percentage rebate for various Mean Opinion Scores
15

57. 3.10 Summary of the Role of Various Components of the
System
In order to give a

58. nal overview of the physical components of the billing system the steps
performed by each device involved in the billing process are listed below.
3.10.1 Measurement Device
1. The measurement device detects a call by reading either a SIP CONNECT message
or an H.245 message
2. The call is identi

59. ed uniquely as two RTP streams which have unique IP addresses
and port numbers
3. The measurement device monitors sequence numbers and assigns each packet a time
based on the GPS clock
4. Every 10 seconds (and at the end of the call) the measurement device transmits
compressed information about the sequence numbers, codecs and timestamps of the
packets sent and received by the client to the consolidation server. This transfer is
sent over the IP network using HTTPS over SSL in order to ensure the security of
the connection [21].
3.10.2 Consolidation Server
1. The consolidation server uses the information sent to it from the measurement device
in order to calculate delays and packet losses
2. The consolidation server then uses the calculated delays and packet losses as well as
the codec used to determine an R factor
3. The consolidation server then converts these R factors to MOS
4. The resulting MOS for each 10 second call segment is compressed and transmitted
to the billing server over the IP network using the OSP protocol. This protocol is
used as it provides tools for standard messages which are used for communicating
with billing servers [22].
3.10.3 Billing Server
1. The billing server receives the MOS for each 10 second call segment
2. The billing server writes each 10 second MOS and the average MOS for a call to a
database which records the call participants, length and quality
3. At month end the billing information stored on the billing server is used to calculate
the client's total rebate for that month
16

60. 4 CRITICAL ANALYSIS OF PROPOSED
SOLUTION
4.1 Simulation
In order to validate the equation for determining R factor from network parameters a
simple network simulation was employed. In this simulation a network connection was
modeled by introducing losses and delays to a series of simulated data packets. In order to
realistically model an IP network a number of mathematical models for network behavior
were employed as described below.
Firstly delays for each packet were distributed about the mean delay with a gamma
distribution as described in [23], secondly a four state Markov model was used for the
modeling of packet losses as described in [12] and [13] and

61. nally a jitter buer was
simulated using the equations found in [13].
The network model was used to create delays and losses in a simulated data stream,
following this the R factor for the data stream was determined using both Equation 13 and
the methods proposed in [13]. An exponential

62. t was then applied to the data determined
using Equation 13 the resulting equation was compared to the graphs generated using the
Markopoulou method in [13].
4.1.1 Eect of Losses on R Factor for Various Codecs
In order to compare the resulting R factors for various codec due to packet losses network
delays were set to zero and then R factors were calculated for various percentage packet
losses. This process was performed for the three codecs for which values for the eect of
codec losses are given in [12], namely G.711, G.729 and G.723. This was deemed sucient
for testing of this proof in concept design but should be extended to other codecs if the
design is put into practice.
Figure 5 to Figure 7 show the results of this series of simulations. In each of these

63. gures the R factor calculated using Equation 13 is shown in red and the R factor calcu-
lated using Markopuolou's method from [13] is shown in green. Finally a third graph is
provided in blue, this graph is the R factor obtained using Equation 13 which has then
been y shifted so that it has the same ideal zero loss R factor as used in [13] for the
given codec.
Clearly for each of these codecs the results obtained using Equation 13 follow an
extremely similar shape to those obtained in [13] and once the graphs have been adjusted
to have the same ideal R factor for each codec the graphs show a great deal of similarity.
The correlations for the shapes of all of these graphs were calculated and they were all
found to be 0.995 or better.
17

64. Figure 5: R factor comparison for G.711 with PLC using bursty packet losses
Figure 6: R factor comparison for G.729 using bursty packet losses
.
18

65. Figure 7: R factor comparison for G.723 using bursty packet losses
4.1.2 Eect of Delay on R Factor
Figure 8 shows how the impairment factor due to delay, Idd, varies with an increase in the
mean absolute delay. As with the eect of losses the values calculated by the algorithm
used for this design are compared to the values obtained in [13]. Due to the fact that the
the eects of codecs are negligible in terms of the eect of network delay emodel[13] the
graph does not consider various codecs. The red line in this graph shows Idd as calculated
using Equation 5, the green line shows the results obtained in [13] and

66. nally the blue
line shows the result obtained from Equation 5 after scaling. This scaling is done to show
that the graph obtained using Equation 5 follows the same basic shape as that obtained
from [13] and is dierent by a simple scaling factor.
4.2 Analysis of Design
The design proposed in this report gives the full speci

67. cation for a QoS aware VoIP billing
system from the basic components of that system all the way up to the algorithms and
techniques which are used in that system. The goal of the design was to produce a billing
system which is capable of extracting QoS data from a VoIP call in a non intrusive way,
calculating a tari based on that quality of service data for various codecs and

68. nally
being able to record this data without decreasing the performance of the IP network. All
of these goals are achieved in the design discussed in this report. Additionally the design
developed was developed in such a way as to make it as accurate and secure as possible
in order to ensure that users are correctly and fairly billed for their calls.
The equations used to calculate quality of service based on network trac data are
veri

69. ed through simulation and comparison with existing models. This simulation clearly
19

70. Figure 8: Idd with increasing mean delay
shows that the results obtained using the proposed equation are comparable with the
results which are found using existing solutions. In general the results obtained only
require simple scaling or shifting in order to very closely approximate results such as
those given in [13].
One trade o of the design discussed in this report is the fact that the equations
used for calculation the equipment impairment factor, Ie, are complicated and require
numerous computations. This results in a system which is not as ecient as it could be in
terms of the amount of time taken to calculate QoS, however it also results in an accurate
measure of the impairment to QoS due to network parameters which is important for
billing applications.
The design speci

71. ed in this report is a proof of concept designs and throughout the
design many assumptions were made based on this fact. These assumptions require fur-
ther investigation before the design could be physically implemented. The assumptions
made and recommendations on how they can be altered or improved are given in the
recommendations for future work below.
4.3 Recommendations for Future Work
The primary assumption made during this design was the assumption that all of the calls
being made were within a single VoIP network which could be accessed at any point.
This allows a proof of concept for QoS measurement to be illustrated but it leads to the
neglecting of a number of important scenarios such as calls between VoIP devices and
regular PSTN devices and perhaps more importantly calls which occur between dierent
IP networks which are operated by dierent companies or groups. In order for this design
20

72. to be realized these situations would have to be considered.
The simulation of the algorithms used in this design show that the algorithms pro-
duce graphs with an extremely similar shape to those developed in other papers but often
required osets and scaling. This dierence is largely due to the fact the mean opinion
scores and default values for QoS measurements dier from paper to paper. In order to
ensure that the QoS scores generated by this design are relevant to a physical implemen-
tation studies should be conducted which directly measure the QoS experienced by users
under various network conditions for this system. The algorithms presented in this design
should then be altered in order to

73. t the data obtained from these studies.
Finally the design focuses only on network trac parameters such as losses and delay
and does not take into account many other factors which can have a large eect on
perceived quality of service such as echo and audio clipping. It can be argued that these
factors can be ignored as they are not the direct responsibility of the service provider,
however these factors do still have an eect on QoS and should at least be considered in
future revisions of this design.
4.4 Social, Economic and Environmental Impact
The design proposed in this report has clear social and economic rami

74. cations due to the
fact that the design is used for providing a service and billing for that service.
When developing a billing system it is important to ensure that the system is designed
in such a way that it is secure and cannot be easily tampered with. This protects both
the company which implements the system and the users of the system as it allows billing
to be fair and consistent. This design attempts to ensure this type of security in the
choice of measurement methods and communications of measurements between various
components of the system.
The calculation of quality of service used in this design is largely based on psychological
and perceived factors. This can be considered an unfair method of billing as the data
obtained is subjective and assumes that people's experience of the quality of a call can be
averaged and applied to others. It is, however, impossible to develop a purely subjective
test for quality of service due to the fact that by de

75. nition quality of service for audio data
is a measure of how a person perceives that data, therefore any billing scheme developed
which uses QoS as a metric will be in some way subjective.
Due to the fact that QoS cannot be guaranteed in an IP network the use of a billing
system which gives rebates when quality of service is poor is advantageous to the users of
VoIP systems as it allows them to only pay the full price for calls when they are receiving
the quality of service which they expect from their service provider. This also encourages
companies to ensure that the QoS which they provide is as high as possible so that they
receive the full tari.
The environmental impact of the proposed billing system is extremely small as it does
not require a large increase in network infrastructure and merely involves the strategic
placement of measurement devices and servers which connect to the existing IP network.
21

76. 5 CONCLUSION
In this report the goal of proposing a proof of concept design which allows users to be
compensated when their network service provider is unable to provide agreed upon quality
of service levels is achieved. The quality of service measurement system discussed in this
report is designed to be able to accurately extract network trac performance data from
a VoIP call by simply reading the headers of packets carrying the call's audio data. This
information is then used in order to determine a quality of service metric for that call
which in turn de

77. nes the rebate which a user will receive based on the quality of service
they experience. The amount of data transmitted and recorded in this billing system is
minimized through the use of compression algorithms.
The QoS calculation method designed in this report is simulated using realistic network
models and is shown to produce similar results to existing QoS measurement systems. A
correlation between the data generated by this design concerning the eect of packet
losses on QoS is found to have a correlation of 0.995 or better when compared to the
data obtained from existing solutions. The shortcoming of the method implemented
QoS estimation is the fact that it is computationally intensive in order to increase its
accuracy and therefore is potentially slower than necessary, however this loss of speed is
less important than billing accuracy.
The proposed design is based on a series of simplifying assumptions which allow the
concept of the implementation of a QoS aware VoIP billing system to be demonstrated,
however many of these assumptions do not necessarily re
ect real world conditions and
future work should extend the design proposed in this report to include multiple networks
and connections between VoIP and PSTN systems. Furthermore the quality of service
scores determined by this design should be calibrated against quality of service scores as
rated by users of the service in order ensure that the scores realistically re
ect the quality
experienced by the users.
ACKNOWLEDGEMENT
Aspects of the design, research and simulation components of this project were performed
as part a group. The author would like to acknowledge his group members: Dylan Yu-
daken, Alexander Pope, Duane Churms and Bjorn Olsen.
22

78. References
[1] D. J. J. Versveld, W. C. Venter, A. S. J. Helberg, and F. J. Scholtz. Voice Over
Internet Protocol Detail Records for the Session Initiation Protocol., 2003.
[2] Y. Jiang, C.-K. Tham, and C.-C. Ko. Providing Quality of Service Monitoring:
Challenges and Approaches. Department of Electrical Engineering, Natuional Uni-
versity of Singapore, 2000.
[3] A. Raja, R. M. A. Azad, C. Flanagan, and C. Ryan. Real Time, Non-intrusive
Evaluation of VoIP. University of Limerick, Ireland, 2007.
[4] J. Prokkola and M. Hanski. QoS Measurement Methods and Tools. VTT Technical
Research Centre of Finland, 2005.
[5] International Telecommunication Union. G.107 -The E-model, a computational model
for use in transmission planning, 2000.
[6] D. D. Vleeschauwer, J. Janssen, G. H. Petit, and F. Poppe. Quality bounds for
packetized voice transport. Alcatel Telecommunications Review, pp. 19 { 24, 2000.
[7] M. Goudarzi, L. Sun, and E. Ifeachor. PESQ and 3SQM measurement of voice qual-
ity over live 3G networks. School of Computing, Communications and Electronics,
University of Plymouth, UK, 2007.
[8] D. Mills. Experiments in Network Clock Synchronization. M/A COM Linkabit, 1985.
RFC957.
[9] W. Lewandowski, J. Azoubib, and W. Klepczynski. GPS:primary tool for time
tranfer. Proceeding of the IEE, vol. 57, pp. 163{172, 1999.
[10] V. Paxson. On calibrating measurements of packet transit times. Lawrence Berkely
National Laboratory, Network Research Group, 1998.
[11] International Telecommunication Union. P.862 - Perceptual evaluation of speech
quality (PESQ), 2001.
[12] A. Clark. Extensions to the E Model to incorporate the eects of time varying
packet loss and recency. Telchemy Incorporated, 2001.
[13] A. P. Markopoulou, F. A. Tobagi, and M. J. Karam. Assessing the Quality of Voice
Communications Over Internet Backbones. IEEE/ACM Transactions on Network-
ing, vol. 11, pp. 747{760, 2003.
[14] J. F. Kurose and K. W. Ross. Computer Networking: A Top-Down Approach, chap.
7: Multimedia Networking. Addison-Wesley, 2007.
[15] A. Raake. Assessing the Quality of Voice Communications Over Internet Back-
bones. IEEE Transactions on Audio, Speech and Language Processing, vol. 14, pp.
1957{1968, 2006.
[16] Rosenberg et. al. SIP: Session Initiation Protocol. Internet Engineering Task Force,
2002. RFC 3261.
23

79. [17] Handley et. al. SDP: Session Description Protocol. Internet Engineering Task
Force, 2006. RFC 4566.
[18] H. Liu and P. Mouchtaris. Voice over IP signaling: H.323 and beyond. IEEE
Communications Magazine, vol. 38, pp. 142{148, 2000.
[19] International Telecommunication Union. H.245 - Control Protocol for Multimedia
Communication, 2008.
[20] Schulzrinne et. al. RTP: A Transport Protocol for Real-Time Applications. Net-
work Working Group, 2003. RFC 3550.
[21] E. Rescorla. HTTP over TLS. Internet Engineering Taskforce, 2000.
[22] ETSI. Open Settlement Protocol for Inter-Domain Pricing, Authorization and Usage
Exchange. Internet Engineering Taskforce, 2003.
[23] A. Corlett, D. I. Pullin, and S. Sargood. Statistics of One-Way Internet Packet
Delays. 53 IETF, 2002.
24