QUALITY OF SERVICE AWARE TARIFF MODELSFOR VOIP CALLS

School of Electrical & Information EngineeringUniversity of the Witwatersrand

.Neal Derman

0405238T

August 21, 2009

Abstract

Many telecommunications service providers are beginning to implement IP based so-lutions for telecommunications. In order for IP based technologies to be competitive theymust 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 whichallows a user’s tariff to be reduced when they experience a lower than acceptable qualityof service for a given call. This system must extract quality of service data and recordbilling information while having minimal impact on network performance.

A design is proposed for an entire quality of service billing system which incorporateselements such as call detection, network data extraction, subjective quality of serviceestimation 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 realisticnetwork models and is shown to be comparable to existing quality of service estimationalgorithms.

The proposed design is able to accurately extract network traffic data and determinea billing rebate based on this data. The data is extracted using simple methods and thebilling data generated is minimized by the use of compression techniques. Some efficiencyin the calculation of quality of service is sacrificed in order to allow the estimated qualityof service to be determined as accurately as possible.

The accuracy of the quality of service measurements obtained by this design could befurther improved by using subjective quality of service measurements in order to calibratethe quality of service estimation equations. The proposed design is also heavily reliant onthe assumption that the IP network on which it will be implemented is self contained andfully accessible and this assumption should be reevaluated as a possible improvement tofuture work.

Contents

1 INTRODUCTION 1

2 BACKGROUND AND EXISTINGSOLUTIONS 12.1 Assumptions and Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 12.2 Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3 Traffic Data Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.4 Synchronization of Measurements . . . . . . . . . . . . . . . . . . . . . . . 32.5 Existing Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 BILLING SYSTEM DESIGN 43.1 Design Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.2 Design Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.3 Calculation of QoS From Call Data . . . . . . . . . . . . . . . . . . . . . . 5

3.3.1 Traffic Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.3.2 The E-Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.4 Derivation of Final QoS Algorithm . . . . . . . . . . . . . . . . . . . . . . 73.4.1 Signal to Noise Ration . . . . . . . . . . . . . . . . . . . . . . . . . 83.4.2 Simultaneous Impairment Factor . . . . . . . . . . . . . . . . . . . 83.4.3 Delay Impairment Factor . . . . . . . . . . . . . . . . . . . . . . . 83.4.4 Equipment Impairment Factor . . . . . . . . . . . . . . . . . . . . 93.4.5 Advantage Factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.4.6 Final Modified E-model Equation . . . . . . . . . . . . . . . . . . . 10

3.5 Calculating MOS from R Factor . . . . . . . . . . . . . . . . . . . . . . . 103.6 Call Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.6.1 Session Initiation Protocol . . . . . . . . . . . . . . . . . . . . . . . 113.6.2 H.323 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.7 Measurement of Network Data . . . . . . . . . . . . . . . . . . . . . . . . 133.7.1 Data Extraction from RTCP . . . . . . . . . . . . . . . . . . . . . 133.7.2 Data Extraction from RTP . . . . . . . . . . . . . . . . . . . . . . 13

3.8 Data Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.9 Billing System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.10 Summary of the Role of Various Components of the System . . . . . . . . 16

3.10.1 Measurement Device . . . . . . . . . . . . . . . . . . . . . . . . . . 163.10.2 Consolidation Server . . . . . . . . . . . . . . . . . . . . . . . . . . 163.10.3 Billing Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 CRITICAL ANALYSIS OF PROPOSEDSOLUTION 174.1 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1.1 Effect of Losses on R Factor for Various Codecs . . . . . . . . . . . 174.1.2 Effect of Delay on R Factor . . . . . . . . . . . . . . . . . . . . . . 19

4.2 Analysis of Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.3 Recommendations for Future Work . . . . . . . . . . . . . . . . . . . . . . 204.4 Social, Economic and Environmental Impact . . . . . . . . . . . . . . . . 21

5 CONCLUSION 22

List of Figures

1 A conceptual overview of the design for the proposed VoIP billing system 62 MOS for varying R factors . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Compression ratio for various amounts of data using gzip compression . . 154 Percentage rebate for various Mean Opinion Scores . . . . . . . . . . . . . 155 R factor comparison for G.711 with PLC using bursty packet losses . . . . 186 R factor comparison for G.729 using bursty packet losses . . . . . . . . . . 187 R factor comparison for G.723 using bursty packet losses . . . . . . . . . . 198 Idd with increasing mean delay . . . . . . . . . . . . . . . . . . . . . . . . 20

1 INTRODUCTION

Many telecommunications providers are moving away from traditional PSTN networksand are beginning to implement IP based solutions for telecommunications [1]. Thesesolutions allow service providers to consolidate their services into a single network whichwill provide support for various multimedia applications [2]. For the new integratedservices networks to be able to compete with the existing PSTN network they must beable to provide a level of quality of service guarantees which are acceptable to the usersof 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 networkservice provider is unable to deliver an appropriate level of service quality. In order forthis type of billing system to be implemented a method of non-intrusively extracting QoSand converting this quality of service to tariff must be designed, additionally the datacollected and recorded in order to allow billing should minimally interfere with normalnetwork 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 servicemeasurement tools such as the synchronization of network data measurements. Some ofthe existing quality of service measurement tools are also discussed briefly.

Section 3 gives a top to bottom design of an entire billing system which meets thecriteria stipulated above. The proposed design covers the entire billing system from thedetection of VoIP calls all the way to the actual calculation of a billing rebate based onthe measured quality provided in a given call.

In Section 4 the QoS calculation aspect of the design is simulated and compared withexisting QoS measurement solutions so that the design can be critically analyzed. Thiscritical analysis yields suggestions for future work and improvements to overall design.Finally the social, economic and environmental impact of the proposed design is discussedbefore 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 billingsystem a number of assumptions were made in order to reduce the complexity of thedesign so that the basic concept can be illustrated. The primary assumptions made arethe fact that the entire network of interest is fully controlled by the company implementingthe billing system and therefore network performance measurements can be taken at anypoint in the network. This assumption makes it possible to measure the quality of serviceof a call without requiring access to another company’s network. A second assumptionis that all calls to be billed for are VoIP to VoIP calls. This means that separate billingmodels need not be developed for different types of calls and therefore the billing model issimplified. Finally it is assumed that the billing system to be used is post pay and not prepay, this implies that the billing system need not be fully real time in terms of applyingany rebate for reduced quality of service during the call. The quality of service can be

1

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 performanceinformation must be extracted quickly without compromising the speed of the transmis-sion. Secondly a minimal amount of traffic data must be generated and transmitted bythe billing system in order to ensure that the billing system does not contribute excessiveamounts of network traffic.

2.2 Quality of Service

Quality of service (QoS) is a representation of the quality which is provided by a networkprovider with respect to whatever services they are offering 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 fromnetwork performance. It is determined from factors such as packet loss, jitter, delays etc.and gives a quantitative measure of the quality of network traffic in a network [4].

Subjective quality of service is the quality of a given service as perceived by the userof that service [3][4]. For multimedia applications the perceived quality is the qualitywhich the user actually experiences. Therefore in order to develop a billing system whichaccounts for quality of service the perceived or subjective quality of service must bemeasured or approximated.

The subjective quality of service for a VoIP call could be measured by allowing eachuser to rate their call at the completion of the call. However this type of system couldnot be used for a billing system as the user could simply give all calls a lower rating inorder to decrease their bill. For audio applications such as VoIP a number of systemsexist which map objective quality of service measurements such as delay and packet lossto approximations of the perceived quality which the user will experience [3][5][6]. Inorder to map objective factors to subjective QoS a method of rating a given call mustbe used. Many of the popular algorithms, such as the ”E Model” and PESQ, which areused 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 from1 to 5, these ratings are then averaged over all of the subjects in order to determine theMOS [3]. The MOS can be measured under different network traffic conditions in orderto determine how various objective network traffic factors affect the subjective QoS of anaudio signal transmitted over a network.

For this design a simple algorithm was developed which allows the mapping of networktraffic data to MOS scores in real time.

2.3 Traffic Data Measurement

There are two main methods for measuring network performance, active and passivemethods [4]. Active methods involve generating known network traffic and transmittingit on the network [4]. This allows the sent data to be compared with the received datain order to determine how the network is performing at a given point in time. This typeof measurement system is not useful for a billing application as it does not provide real

2

time information about actual network traffic. Passive systems involve the extraction ofnetwork data from existing network traffic in order to determine the network performance[4]. This type of system is applicable to a billing system as it allows network performancedata to be extracted in real time from current network traffic. This real time data canthen 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, specifi-cally the measurements can be taken at a single point, at the endpoints of a traffic streamor at multiple points in the network [2][4]. Single point measurements are not an accuratemethod of measuring network performance due to the fact that they require the generallyfalse 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 becauseQoS can be measured between each measurement point [2][4]. End to end measurementsare sufficient for determining the QoS of a given traffic stream between those points [2][4].For a billing application end to end measurements are sufficient as the location of thecause of QoS degradation is not relevant to the billing and distributed measurement overmultiple points requires higher overheads as more measurement devices are required andmore measurements are made.

For this design it was determined that end to end measurements are sufficient in orderto provide accurate network performance data.

2.4 Synchronization of Measurements

In order for accurate network performance measurements to be taken using an end toend 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 beachieved using a number of techniques.

Some techniques use a network protocol such as Network Time Protocol (NTP) tosynchronize 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 transmissionof clock information across the network [8] and current algorithms such as NTP are notsufficiently accurate for delay measurements in modern networks [4]. Due to the factthat this method requires transmission of time information over the network a furtherinaccuracy is introduced as network delays will affect the arrival of timing informationand 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 hasan 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 areradio 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 GPSconnection [2][9].

In [10] Paxson argues that even a well synchronized clock is not sufficient for accuratenetwork 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 delaymeasurements. In order to ensure consistent accuracy of delay measurements algorithmssuch as those described in [10] can be used in order to detect sudden clock changes and

3

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 centralclock and that algorithms for correcting clock instability should be included in the softwareof the measurement devices.

2.5 Existing Algorithms

A number of algorithms exist for determining the QoS of an audio signal. Describedbelow are some of the commonly used algorithms for determining QoS from networkperformance.

Perceptual Evaluation of Speech Quality (PESQ) is a set of ITU-T standards whichare used to calculate perceived quality of service by sending a reference signal over anetwork and comparing the received signal to the sent signal [7][11]. Due to the fact thatit requires comparison with a reference signal and is computationally intensive PESQ isnot 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 whichultimately results in a simple series of equations which can determine a PESQ-like MOSscore in real time.

The E-model is an ITU-T standard used for transmission planning [5]. The E-modeluses network traffic parameters to determine a MOS as described above [5][6]. Essentiallythe E-model is a series of equations used to find a ”R factor” which can be used to finda 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 onnetwork traffic factors and other objective and subjective measurements and can thereforepotentially 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 factthat it calculates a subjective QoS score based on network traffic data [7]. 3QSM is notsuited for a billing application as it does not predict the subjective quality as well as othermethods 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 entirebilling and measurement system was considered and a basic design was determined. Thisdesign incorporated basic features such as the type of measurements to be taken, thelocation of these measurements and a basic idea of how these measurements would betranslated into a final billing scheme.

The basic design was then broken into smaller subsystems which could then be designedin isolation in order to achieve the final goal of designing a QoS aware VoIP billing system.The main subsystems which make up the overall design of the billing system are: themethod of extracting network data from a VoIP call, the algorithm for translating thiscall data into a meaningful QoS score which can be used for billing and finally the billing

4

system itself which is used to consolidate the QoS data in order to determine how acustomer 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 VoIPcall. This provides an end to end measurement of the network performance experiencedon the IP network. These measurements are made by a black box measurement systemwhich could be a network device in its own right or could be a software applicationrunning on a router or server. As described above the measurement systems will includeGPS synchronization technology and will implement algorithms to ensure that the clocksof these devices remain stable and accurate. This design measures the end to end qualityof service between the routers on the edges of the network when a call is made. For thismeasurement to be considered accurate the inherent assumption is made that the QoSdegradation experienced between the client computer and the router on the network edgewill 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 aconsolidation server. Although not depicted in the conceptual diagram this transmissionwill occur over the IP network on which the VoIP calls occur. The data transmitted to theconsolidation server will be compressed in order to help minimize the amount of networktraffic which is generated by the billing system. The consolidation server will use the datait receives in order to calculate simple objective QoS metrics such as average delay, totallosses 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 theIP network to the billing server. The billing server is used to keep track of all of the callswhich have been made and to record any rebates which must be awarded to a client dueto reduced QoS of a call. When the clients are billed a record of the billing informationcan 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 objectivenetwork traffic parameters. Discussed below are the various traffic parameters which canhave an effect on quality of service as well as a description of the algorithm which is usedin this design in order to approximate perceived quality of service.

3.3.1 Traffic Parameters

The primary factors which affect the quality of transmitted voice data are [12][13]:

• Packet loss

• Jitter

• Delay

• Clipping Effects

• Echo

• Audio Encoding

5

Figure 1: A conceptual overview of the design for the proposed VoIP billing system

Packet loss affects the quality of the audio signal because it results in a loss of voicedata at the receiving client. The effects of packet loss on audio quality are dependent onhow 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 packetswhich are lost together. The effects of individual packet losses can usually be correctedfor or reduced by using a Packet Loss Concealment (PLC) algorithm which attempts todisguise 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 nonconstant delay factors, such as queuing delays at routers [14]. Jitter can result in packetsarriving out of order or with an extremely variable rate and can lead to large degradationof audio quality [14]. By use of a protocol such as Real Time Protocol (RTP) whichprovides packet numbers and timestamps jitter can essentially be converted to packetlosses and delays by use of a jitter buffer which buffers packets for a preset or variabletime period in order to remove jitter and discards packets which do not arrive withing thetime period [14][15].

In order to maintain acceptable levels of audio quality end to end delays should notexceed 400ms [14] and should be in the order of 100 - 200ms [13][14]. End to end packetloss encompassed all losses experienced in a given audio stream.

The audio encoding has a large effect on the quality of service achieved for a numberof reasons. Firstly various audio encodings have different levels of compression, thisboth directly affects the quality of the audio being transmitted and also weights theimportance of packet losses [13]. Encoding techniques with higher levels of compressionwill generate packets which contain more audio data per packet, this means that the higherthe compression the larger an effect packet loss will have on audio quality. Audio encodingalso affects quality because different encodings use different techniques for dealing withlost and out of order packets as described above.

6

Clipping (due to audio detection devices which start recording when a sound is playedand stop when the sound ends [15]) and echo (due to speaker volume and reflection ofsignals [13]) are extremely difficult to determine from measurements of network trafficand are therefore not considered in this proof of concept design.

The final algorithm implemented for QoS calculation is based on the E-model and usesmeasurements of packet loss, delay and audio encoding in order to estimate a perceivedQoS.

3.3.2 The E-Model

As discussed above the E-model is an ITU-T standard used for transmission planningand real time network quality analysis [5][12]. The E-model attempts to approximate theaudio quality experienced by a client by taking into account a number of ”psychologicalfactors”[5]. According to [5] the psychological factors considered in the E-model can beconsidered 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 audiotransmission.

R = Ro − Is − Id − Ie + A (1)

Each term of the E-model equation is described briefly below, these definitions arethose given in [5].

• Ro - The basic signal to noise ratio for the transmission

• Is - The simultaneous impairment factor, the sum of all impairments which mayoccur 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, basedon 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 final 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 Traffic Parameters section above the factors which contribute to QoSwhich cannot be directly measured from network traffic are not considered in this design.Therefore the only E-model factors which are of interest are those directly related to net-work traffic parameters. The factors which are not related to network traffic are assumedto have their default values as described in [5]. Additionally the equipment impairmentfactor is calculated using the equations found in [12] which allow recency and the time ofpacket loss to be included in the algorithm.

7

3.4.1 Signal to Noise Ration

The signal to noise ratio for the E-model is given by Equation 2 where SLR is theSending Loudness Rating(a measure of the loudness of the audio signal sent through themicrophone by the sender) and No is the power addition of background and circuit noisesources [5].

Ro = 15− 1.5(SLR + No) (2)

Because the sending loudness and the circuit and background noise cannot be extractedfrom the network traffic detected by the measurement device used in this design the valueof 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 impairmentdue to too low Output Loudness Rating, Ist gives the impairment due to non-optimumside tones and Iq gives the impairment due to quantizing distortion [5]. None of thesefactors can be directly measured from network traffic and Is is therefore assumed to haveits default values for all of it’s components. The final default value of Is can be shownto be 0.44018 by substituting the default values in [5] into the equations for each of itscomponents.

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 measureddirectly 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 defined as the impairment due to an absolute delay (Ta) [5]. When Ta is longerthan 100ms Idd is given by Equation 5, where X is given by Equation 6 [5]. When Ta isless than 100ms Idd is 0 [5]. This means that absolute delay has no effect on QoS whenit is less than 100ms which is in line with the statement in [14] which says that absoluteend to end delays of less than 150ms are imperceptible to humans.

Idd = 25

{(1 + X6)

16 − 3

(1 +

[X3

]6) 16

+ 2

}(5)

X = log2

( Ta

100

)(6)

8

3.4.4 Equipment Impairment Factor

The equipment impairment factor represents the effect of network equipment on the qual-ity of service of a call [5][12]. The effect of different network conditions on this factor aredetermined by using MOS [5]. In [12] Clark provides a method for calculating Ie whichtakes into account the types of loss conditions being experienced on the network. Clarkmakes use of a Markov model which defines two main network loss conditions ”bursty”and ”gap.” Bursty conditions occur when the network is experiencing a high number oflosses whereas gap conditions occur when losses are infrequent (here the term ”gap” refersto gaps between packet losses) [12].

In the Markov model a network can move between the bursty and gap states withvarious probabilities for different kinds of movement between the states [12]. In orderto 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]. Inthese equations b and g are the length of a given burst or gap state in seconds [12]. Theseequations have an exponential form as the perceived quality of service for a given networkstate ”decays” from a bursty state into a gap state and vice versa [12], for example thenetwork becomes slowly less and less bursty over time as it becomes more gap like andthe users perception follows this trend.

I1 = Ieb − (Ieg − I2)e−bt1 (7)

I2 = Ieg − (I1 − Ieg)e−gt2 (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, delayvariation and codec used as shown in Equation 9 and Equation 10 which are taken from[12]. As discussed above the assumption that jitter buffers are used means that the effectof delay variation can be assumed to be 0 for these equations. The impairment values forcodecs 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 impairmentfactor for an audio stream, this is given by Equation 11 [12].

Ie(average) =(bIeb + gIeg − t1(Ieb − I2)(1− e

−bt1 ) + t2(I1 − Ieg)(1− e

−gt2 ))

(b + g)(11)

In order to take into account the fact that the point in a call at which quality lossoccurs affects the client’s perception of the quality of that call a further adjustment ismade to the calculation of the equipment impairment factor. In order to adjust thecalculation of equipment impairment the assumption is made that any sudden increasein equipment impairment factor will result in a loss of quality of service, the equipment

9

impairment factor will then exponentially decay back to the current average equipmentimpairment factor [12]. This is done to take into account the psychological effect knownas recency which results in people weighting a decrease in quality of service towards theend of a call more heavily than one which occurs earlier in a call [12]. The final result ofthis assumption is Equation 12 which describes the behavior of the equipment impairmentfactor after a sudden increase in impairment, in this equation t3 is 30, k is 0.7 and y isthe delay since the last bursty packet loss [12].

Ie(recency) = Ie(average) + (k(I1 − Ie(average)))e−yt3 (12)

3.4.5 Advantage Factor

Advantage factor represents the advantage gained by having access to the service beingprovided [5]. The advantage factor increases if the service being provided is one which isnot easily provided or if there is some other reason that a loss of QoS could be toleratedor expected for this service. In [5] example advantage factors are given as a guideline:Conventional telecommunications are given an advantage factor of 0 whereas providingtelecommunications 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 purelyconcerned with a proof of concept VoIP system which operates within an individual IPnetwork.

3.4.6 Final Modified E-model Equation

After all of the simplifying assumptions and additions made to the E-model, as describedabove, a final equation for the calculation of R scores from network traffic parameters isderived. The final algorithm used is shown in Equation 13 where Ie and Idd are as definedabove. As Ie is dependent purely on losses and codec and Idd is dependent purely onabsolute network delay the goal of developing an equation for estimating audio QoS basedsolely on factors which can be extracted directly from network traffic 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 canbe compared to other QoS measurements the R factor scores generated must be convertedto MOS. The E-model provides an equation for converting R factor to MOS as shown inEquation 14 through Equation 16 [5]. Figure 2 shows graphically how MOS varies withR factor as per these equations.

ForR < 0 : MOS = 1 (14)

For0 < R < 100 : MOS = 1 + 0.035R(R− 60)(100−R)7.10−6 (15)

ForR > 100 : MOS = 4.5 (16)

10

Figure 2: MOS for varying R factors

3.6 Call Identification

In order to calculate the QoS of a VoIP call network data about the call must be measuredand extracted. In order to do this the call must first be detected. Once the call has beenidentified it must be monitored and information about the call must be recorded. Thisdetection process is performed by the measurement system depicted in Figure 1. Thedesign discussed in this report assumes that the protocol to be used for the actual calltransmission will be the RTP protocol. RTP was chosen as it provides mechanisms whichhelp to detect losses or delays in packets and because it is a widely used protocol fortransmission 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 standardsthe measurement device must be able to identify calls which are initiated using eitherof these technologies. What follows is a description of how each of these technologiesinitiates 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 networkand to negotiate the conditions of that call such as the encoding, port and protocols tobe used [14][16].

A SIP call is initiated when the caller sends an ”INVITE” message to either the personto be called (in the case of a known IP address) or to an SIP proxy server when the callee’sIP address is not known to the caller [14]. The INVITE message contains an identifierfor the person who is being called, the IP address of the caller, the audio encoding which

11

will be used for the call and finally the protocol and port which the caller will be usingfor the VoIP call which will be established [14][16]. The IP address of the caller as wellas 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 thecallee by the SIP proxy server [14]. If the protocol and encoding are supported by thecallee 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 forthe 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 thecallee throughout the call [14] therefore the IP addresses and port numbers are sufficientto uniquely identify a particular VoIP call. The measurement device used will thereforebe 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 containthe 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 layerprotocols such as SIP.

In order for billing to be performed correctly the measurement device must also becapable 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 besent by either of the parties involved in the call [16]. The call is terminated when an OKresponse is received after a BYE message. The measurement device will mark the end ofa call when a BYE message is responded to with an OK message or when the call timesout.

3.6.2 H.323

H.323 is another popular standard which is used for call initiation and management on IPnetworks [14]. H.323, if used, defines a series of protocols which must be used for everyaspect of a multimedia call over an IP network [14]. H.323 specifies that the H.245 protocolbe used as a control protocol for the logical setup of a VoIP call and that Q.931 signalingmust be used for the initial call setup and for determination of the H.245 addresses of theparties involved in the call[14][18].

As H.245 is the protocol used to negotiate logical call parameters, such as the IPaddresses, RTCP and RTP ports of the clients which are involved in the call, it is theH.245 messages which must be detected and read by the measurement device in order tobe able to detect and uniquely identify a call which is initiated using H.323 [18][19]. Bydecoding any H.245 messages received at the measurement device calls can be identifiedand monitored, by using the RTP ports and IP addresses of the clients, in a similar wayas specified for SIP above.

An H.245 message is also used to close the logical connections used for the mediastreams between call participants. As with the SIP BYE message discussed above themeasurement device must be capable of detecting this message and appropriately markingthe end of a call.

12

3.7 Measurement of Network Data

As discussed above the audio data will be encapsulated using the RTP protocol. RTPencapsulates real time data which is to be transmitted and appends a header which recordsthe 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 usedto provide statistical information about network performance and give an indication ofthe 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 RTPor 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 monitora VoIP call. As discussed in the section on the derivation of the QoS algorithm abovethe information required from an RTP or RTCP stream, in order to determine the QoSof 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 thenumber of packets lost, the jitter and the timestamps of the RTP stream [1][14] thereforefrom an RTCP packet the delay and loss could be calculated. The only other factorrequired for the determination of QoS using the design equation in this report is thecodec used. This data can be extracted from either the H.245 control messages in acall using H.323 or from the INVITE and OK message interchange in the case of a callusing SIP, as described above. Extraction of QoS relevant data from RTCP can thereforetheoretically be easily achieved by simply decoding both the messages used to initiate thecall and the RTCP packets associated with the streams relevant to that call. The RTCPpacket streams can be identified in a similar manner to the identification of RTP streamsdescribed above, the RTCP stream will use the same IP address as the RTP stream andusually uses the RTP port number plus one [14].

There are, however, a number of problems with this approach when applied to a billingmodel. Firstly the losses indicated by RTCP are just percentage losses for a given streamand do not give an indication of whether these losses occurred as bursts or as individuallosses [14][20]. This information is not sufficient for calculation of Ie (as described above)which requires knowledge of where in a stream the losses occur. The second problem withthe use of RTCP is an issue of security. As RTCP does not carry the actual audio datathe RTCP packets can simply be blocked by the client sending the packets, the actualRTCP packet can then be replaced with an RTCP packet which indicates a much lowerquality of service than the one being experienced in the call. This results in a fraudulentincreased rebate on the client’s tariff.

For these reasons it was decided that the call data should not be extracted from theRTCP 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 headerallows packet losses to be detected and also allows the location and type of losses beingexperienced to be determined because a large number of successive packets lost represents

13

a burst type packet loss. In this way the loss detection achieved by reading RTP headersat 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 thistype of clock has already been deemed insufficiently accurate in the section on synchro-nization of measurements in this report. Instead for accurate delay data a timestamp willbe generated for each RTP packet at the measurement device (which uses GPS clock syn-chronization) and this timestamp will be used for billing. The final piece of informationrequired for the QoS approximation algorithm is the codec which is used to encode theaudio transmission. This information can be extracted from two possible sources: thisdata could be extracted from call initiation data as described in the section on RTCP orthis information can be extracted directly from the RTP header which includes a field for”payload type” which gives the codec used for the audio encoding [14].

RTP does not suffer from the spoofing problem which RTCP experiences due to thefact that the information used in the RTP header is used for correct playout and for jitterbuffering at the receiver [14], this means that RTP header information cannot be alteredwithout impairing the quality of the audio stream.

Extraction of network data from RTP headers was chosen as the preferred method dueto its accuracy for packet losses and due to the fact that it is less susceptible to spoofingthan RTCP.

3.8 Data Compression

In order to minimize the amount of data which is transmitted from the measurementdevice to the consolidation server and from the consolidation server to the billing server acompression algorithm is used. A simple simulation was performed in order to show theeffect of this type of compression. For this simulation numerical data (which is extremelysimilar to the type of data which would be transmitted from the measurement device to theconsolidation in order to convey the timestamp, losses and encoding) was compressed usingthe gzip library. Figure 3 shows the compression ratio ((compressed size)/(uncompressedsize)) for various amounts of data being compressed.

From this figure it is clear that even large amounts of numerical data can be compressedgreatly (to within 1% of its original size) using simple compression methods. This impliesthat the amount of billing data required to be sent over the IP network can be minimizedin 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 customerbills. This allows the system to be applied to any existing or future billing systemswithout needing to know the details of that billing system. In [13] a MOS of greater than4 is deemed ”Desirable” therefore any call with a MOS of greater than 4 does not receive arebate. Similarly any MOS of less than 2.6 is ”not recommended” [13] and for calls belowthis quality a 100% rebate is given. Between these values the rebate is scaled linearly asshown in Figure 4.

14

Figure 3: Compression ratio for various amounts of data using gzip compression

Figure 4: Percentage rebate for various Mean Opinion Scores

15

3.10 Summary of the Role of Various Components of theSystem

In order to give a final overview of the physical components of the billing system the stepsperformed 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 messageor an H.245 message

2. The call is identified uniquely as two RTP streams which have unique IP addressesand port numbers

3. The measurement device monitors sequence numbers and assigns each packet a timebased on the GPS clock

4. Every 10 seconds (and at the end of the call) the measurement device transmitscompressed information about the sequence numbers, codecs and timestamps of thepackets sent and received by the client to the consolidation server. This transfer issent over the IP network using HTTPS over SSL in order to ensure the security ofthe connection [21].

3.10.2 Consolidation Server

1. The consolidation server uses the information sent to it from the measurement devicein order to calculate delays and packet losses

2. The consolidation server then uses the calculated delays and packet losses as well asthe 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 transmittedto the billing server over the IP network using the OSP protocol. This protocol isused as it provides tools for standard messages which are used for communicatingwith 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 adatabase which records the call participants, length and quality

3. At month end the billing information stored on the billing server is used to calculatethe client’s total rebate for that month

16

4 CRITICAL ANALYSIS OF PROPOSED

SOLUTION

4.1 Simulation

In order to validate the equation for determining R factor from network parameters asimple network simulation was employed. In this simulation a network connection wasmodeled by introducing losses and delays to a series of simulated data packets. In order torealistically model an IP network a number of mathematical models for network behaviorwere employed as described below.

Firstly delays for each packet were distributed about the mean delay with a gammadistribution as described in [23], secondly a four state Markov model was used for themodeling of packet losses as described in [12] and [13] and finally a jitter buffer wassimulated 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 andthe methods proposed in [13]. An exponential fit was then applied to the data determinedusing Equation 13 the resulting equation was compared to the graphs generated using theMarkopoulou method in [13].

4.1.1 Effect of Losses on R Factor for Various Codecs

In order to compare the resulting R factors for various codec due to packet losses networkdelays were set to zero and then R factors were calculated for various percentage packetlosses. This process was performed for the three codecs for which values for the effect ofcodec losses are given in [12], namely G.711, G.729 and G.723. This was deemed sufficientfor testing of this proof in concept design but should be extended to other codecs if thedesign is put into practice.

Figure 5 to Figure 7 show the results of this series of simulations. In each of thesefigures 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 isprovided in blue, this graph is the R factor obtained using Equation 13 which has thenbeen ”y shifted” so that it has the same ideal zero loss R factor as used in [13] for thegiven codec.

Clearly for each of these codecs the results obtained using Equation 13 follow anextremely similar shape to those obtained in [13] and once the graphs have been adjustedto 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 allfound to be 0.995 or better.

17

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

Figure 7: R factor comparison for G.723 using bursty packet losses

4.1.2 Effect of Delay on R Factor

Figure 8 shows how the impairment factor due to delay, Idd, varies with an increase in themean absolute delay. As with the effect of losses the values calculated by the algorithmused for this design are compared to the values obtained in [13]. Due to the fact that thethe effects of codecs are negligible in terms of the effect of network delay emodel[13] thegraph does not consider various codecs. The red line in this graph shows Idd as calculatedusing Equation 5, the green line shows the results obtained in [13] and finally the blueline shows the result obtained from Equation 5 after scaling. This scaling is done to showthat the graph obtained using Equation 5 follows the same basic shape as that obtainedfrom [13] and is different by a simple scaling factor.

4.2 Analysis of Design

The design proposed in this report gives the full specification for a QoS aware VoIP billingsystem from the basic components of that system all the way up to the algorithms andtechniques which are used in that system. The goal of the design was to produce a billingsystem which is capable of extracting QoS data from a VoIP call in a non intrusive way,calculating a tariff based on that quality of service data for various codecs and finallybeing able to record this data without decreasing the performance of the IP network. Allof these goals are achieved in the design discussed in this report. Additionally the designdeveloped was developed in such a way as to make it as accurate and secure as possiblein order to ensure that users are correctly and fairly billed for their calls.

The equations used to calculate quality of service based on network traffic data areverified through simulation and comparison with existing models. This simulation clearly

19

Figure 8: Idd with increasing mean delay

shows that the results obtained using the proposed equation are comparable with theresults which are found using existing solutions. In general the results obtained onlyrequire simple scaling or shifting in order to very closely approximate results such asthose given in [13].

One trade off of the design discussed in this report is the fact that the equationsused for calculation the equipment impairment factor, Ie, are complicated and requirenumerous computations. This results in a system which is not as efficient as it could be interms of the amount of time taken to calculate QoS, however it also results in an accuratemeasure of the impairment to QoS due to network parameters which is important forbilling applications.

The design specified in this report is a proof of concept designs and throughout thedesign many assumptions were made based on this fact. These assumptions require fur-ther investigation before the design could be physically implemented. The assumptionsmade and recommendations on how they can be altered or improved are given in therecommendations for future work below.

4.3 Recommendations for Future Work

The primary assumption made during this design was the assumption that all of the callsbeing 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 theneglecting of a number of important scenarios such as calls between VoIP devices andregular PSTN devices and perhaps more importantly calls which occur between differentIP networks which are operated by different companies or groups. In order for this design

20

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 oftenrequired offsets and scaling. This difference is largely due to the fact the mean opinionscores and default values for QoS measurements differ from paper to paper. In order toensure 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 usersunder various network conditions for this system. The algorithms presented in this designshould then be altered in order to fit the data obtained from these studies.

Finally the design focuses only on network traffic parameters such as losses and delayand does not take into account many other factors which can have a large effect onperceived quality of service such as echo and audio clipping. It can be argued that thesefactors can be ignored as they are not the direct responsibility of the service provider,however these factors do still have an effect on QoS and should at least be considered infuture revisions of this design.

4.4 Social, Economic and Environmental Impact

The design proposed in this report has clear social and economic ramifications due to thefact 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 designedin such a way that it is secure and cannot be easily tampered with. This protects boththe company which implements the system and the users of the system as it allows billingto be fair and consistent. This design attempts to ensure this type of security in thechoice of measurement methods and communications of measurements between variouscomponents of the system.

The calculation of quality of service used in this design is largely based on psychologicaland perceived factors. This can be considered an unfair method of billing as the dataobtained is subjective and assumes that people’s experience of the quality of a call can beaveraged and applied to others. It is, however, impossible to develop a purely subjectivetest for quality of service due to the fact that by definition quality of service for audio datais a measure of how a person perceives that data, therefore any billing scheme developedwhich 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 billingsystem which gives rebates when quality of service is poor is advantageous to the users ofVoIP systems as it allows them to only pay the full price for calls when they are receivingthe quality of service which they expect from their service provider. This also encouragescompanies to ensure that the QoS which they provide is as high as possible so that theyreceive the full tariff.

The environmental impact of the proposed billing system is extremely small as it doesnot require a large increase in network infrastructure and merely involves the strategicplacement of measurement devices and servers which connect to the existing IP network.

21

5 CONCLUSION

In this report the goal of proposing a proof of concept design which allows users to becompensated when their network service provider is unable to provide agreed upon qualityof service levels is achieved. The quality of service measurement system discussed in thisreport is designed to be able to accurately extract network traffic performance data froma VoIP call by simply reading the headers of packets carrying the call’s audio data. Thisinformation is then used in order to determine a quality of service metric for that callwhich in turn defines the rebate which a user will receive based on the quality of servicethey experience. The amount of data transmitted and recorded in this billing system isminimized through the use of compression algorithms.

The QoS calculation method designed in this report is simulated using realistic networkmodels and is shown to produce similar results to existing QoS measurement systems. Acorrelation between the data generated by this design concerning the effect of packetlosses on QoS is found to have a correlation of 0.995 or better when compared to thedata obtained from existing solutions. The shortcoming of the method implementedQoS estimation is the fact that it is computationally intensive in order to increase itsaccuracy and therefore is potentially slower than necessary, however this loss of speed isless important than billing accuracy.

The proposed design is based on a series of simplifying assumptions which allow theconcept of the implementation of a QoS aware VoIP billing system to be demonstrated,however many of these assumptions do not necessarily reflect real world conditions andfuture work should extend the design proposed in this report to include multiple networksand connections between VoIP and PSTN systems. Furthermore the quality of servicescores determined by this design should be calibrated against quality of service scores asrated by users of the service in order ensure that the scores realistically reflect the qualityexperienced by the users.

ACKNOWLEDGEMENT

Aspects of the design, research and simulation components of this project were performedas part a group. The author would like to acknowledge his group members: Dylan Yu-daken, Alexander Pope, Duane Churms and Bjorn Olsen.

22

References

[1] D. J. J. Versveld, W. C. Venter, A. S. J. Helberg, and F. J. Scholtz. “Voice OverInternet 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-intrusiveEvaluation of VoIP.” University of Limerick, Ireland, 2007.

[4] J. Prokkola and M. Hanski. “QoS Measurement Methods and Tools.” VTT TechnicalResearch Centre of Finland, 2005.

[5] International Telecommunication Union. G.107 -The E-model, a computational modelfor use in transmission planning , 2000.

[6] D. D. Vleeschauwer, J. Janssen, G. H. Petit, and F. Poppe. “Quality bounds forpacketized 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 timetranfer.” Proceeding of the IEE , vol. 57, pp. 163–172, 1999.

[10] V. Paxson. “On calibrating measurements of packet transit times.” Lawrence BerkelyNational Laboratory, Network Research Group, 1998.

[11] International Telecommunication Union. P.862 - Perceptual evaluation of speechquality (PESQ), 2001.

[12] A. Clark. “Extensions to the E Model to incorporate the effects of time varyingpacket loss and recency.” Telchemy Incorporated, 2001.

[13] A. P. Markopoulou, F. A. Tobagi, and M. J. Karam. “Assessing the Quality of VoiceCommunications 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

[17] Handley et. al. “SDP: Session Description Protocol.” Internet Engineering TaskForce, 2006. RFC 4566.

[18] H. Liu and P. Mouchtaris. “Voice over IP signaling: H.323 and beyond.” IEEECommunications Magazine, vol. 38, pp. 142–148, 2000.

[19] International Telecommunication Union. H.245 - Control Protocol for MultimediaCommunication, 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 UsageExchange.” Internet Engineering Taskforce, 2003.

[23] A. Corlett, D. I. Pullin, and S. Sargood. “Statistics of One-Way Internet PacketDelays.” 53 IETF, 2002.

24