60 THE TRANSACTIONS OF THE SA INSTITUTE OF ELECTRICAL ENGINEERS September 2003

VOICE OVER INTERNET PROTOCOL DETAIL RECORDS

FOR THE SESSION INITIATION PROTOCOL
D J J Versfeld*, W C Venter*, AS J Helberg* and F J Scholtz**

* School for Elec/rical and Elec/ronic Engineering. Po/chef5lroom University for Chris/ian
Higher Educa/ion. P.D. Box 20862. Noordbrug, PO/chefs/room, 2522 Sou/h Africa
** Telkol/1 SA LId. In/egra/ed Technology and Applica/ions S/ra/egy. Priva/e Bag X74.
PrelOria 000 I

Abstract. As the telecommunication industry is moving from a circuit switched network to a

packet switched network, features like Voice over IP, Video over IP, Video on Demand, etc.
will become more important. Currently two protocols for multimedia on packet switched
networks exist. The one is 1-1.323 and the other is the Session Initiation Protocol (SIP). At
this stage, it cannot be determined which one will gain dominance over the market.

The SIP protocol acts as a signalling protocol for the sessions it creates and typical tasks
include initiation, modification and termination of the multimedia sessions. SIP uses the RTP
protocol for transmitting the data of the multimedia sessions. The RTCP protocol is the
control protocol of RTP. The RTCP protocol's primary function is to provide feedback on the
quality of the data distribution.

The purpose of this paper is to examine what data can be extracted from the packet flow
generated between two Session Initiation Protocol (SIP) user agents busy in a call, to derive a
method to extract these data, and to estimate the Quality of Service experienced during the
call from these data. The extracted data could be used to derive detail records.

A network simulation program was used to simulate ome of the Internet's parameters like
packet loss and inter-arrival jitter. A network sniffer was then used to capture the packet flow
between the two SIP user agent, to obtain relevant data. A method to extract information
from the captured data will be described. Data extracted from the SIP messages, the RTP
protocol, the UDP and/or T P and IP protocols include the IP addresses of the originator and
the receiver of the call, the ring time, start time and duration of the call, the amount of data
that was sent and the type of media and codec used. From the RTCP protocol's data, graphs
were drawn reflecting the network's performance experienced during the call. Typical graphs
include Interval Jitter Experienced, Cumulative Packets Sent, umulative Packets Received,
Interval Packet Send Rate, Interval Packet Receive Rate, Interval Payload Data Rate and
Interval Payload Throughput Rate.

It is shown that data necessary to perform detailed usage based billing as well as measuring
the servicc quality for Service Level Agreement purposes can be extracted from the packet
flow.

Key Words. Session Initiation Protocol, Quality of Service, Voice over IP

I. INTRODUCTION Several motives like cost reduction, simplification,

Voice over IP (VoIP) u es IP networks to transport
real-time data for applications like telephony and
real-time video [I]. The public switched telephone
network (PSTN) uses a circuit switched technology
which guarantees high voice quality and high
connection reliability [2]. On the other hand, VolP
usc' the Internet, a packet switched network, which
faces several technical challenges such as loss, delay
and jitter that influence the quality of service of real-
time applications [3].
consolidation and advanced applications promote the
deployment of VolP even with the inferior voice
quality ofVolP when compared to the PSTN [4] and
[5]. When all the advantages of VolP are taken into
account, it is no surprise that most major carriers are
either considering, testing or deploying IP-based
services. The fact that the telecommunication
industries are changing from one technology to
another with different characteristics, results in a
paradigm shift that needs to occur in the billing
architecture. Thus, it is no longer sufficient to use
September 2003 THE TRANSACTIONS OF THE SA INSTITUTE OF ELECTRICAL ENGINEERS 61

the PSTN models that billed users according to the SIPUA

SIPUA 1
time duration and distance of the call [6]. A more
INVITE
effe~tive way will be to bill users according to,
amongst others the type of data, the amount of data, ~. __ ~q~~-y.~g_._._
the quality of service and bandwidth consumption. ro .1.&0 .ll.ffiJNG .
~_1Q.0~ _
The aim of this paper is to examine what data can be
extracted from the packet flow of a SIP session for ACK
the purpose of compiling detail records. The idea is RTP Audio
to insert a non-intrusive data collector into the
network. This data collector must then extract the ~_ BYE

necessary data from the network. ~ _20_Q.. o~ __ •

2. VOIP AND SIP OVERVIEW Fig. 2. Basic SIP call [10]

To ensure compatibility between the different

components of the networks and between the Re:juesl I Response
metnext UXL SIP ~ 0 SIP ~ 0 status reason
different types of networks, network protocols have
Via" SIP ~ 0 protocol mst.port
been developed [7 p.14]. Following the Open From user <sJp jYom_user@Swrce> il
a
."
Systems Interconnection (OSI) model, t~e protocols To. us... <SIp to_user@destmatlon> -"
Call·ID localld@)mt I;l,
comprising the Internet Protocol ~ulte c~n. be CSeg. seqll mzthod III
divided into layers, each layer with a dlstmct length oflxxiy n
Content·Length
Contenl· Type media type of Ixxiy
::a
function [8] and [9, p.526].
lfIariltme
The Session Initiation Protocol (SIP) includes v-O .,
functionality to establish, modify and tern1inate o-CI1~n_usertimestarrqJ llmeslamp IN 1P4 host
e-IN 1P4 ~.g
multimedia essions such as Internet telephony calls. t-O 0 ~D
m"llledta type port RTP/AVP payload types
The SIP protocol is developed by the Internet
Engineering Task Force (IETF). SIP operates at the
application-layer and runs on top of UDP or TCP Fig. 3. Fonnat ofa SIP message [11] and [23].
[10]. RTP and RTCP data are usually transported
using UDP. See Figure I.
3. REAL TIME PROTOCOL (RTP) A D
REAL TIME CONTROL PROTOCOL
HTTP I FTP SIP I RTP I RTCP
(RTCP).
I
rep I UDP
IP
Ethemevr oken Ring! Etc. In the Internet, the RTP protocol acts as a transport
protocol for real-time data streams. RTP consists of
two components. The first is the RTP itself, and the
Fig. I. Protocol stack
second is the Real Time ontrol Protocol (RTCP).
The real time transport protocol (RTP) carrie data
Like HITP, the SIP protocol follows a client-server
that has real-time properties and the RTP control
architecture. Requests are generated by one entity
protocol (RTCP) is responsible for monitoring the
(the client) and sent to a receiving entity (the server),
quality of ervice [13].
where the requests are proces ed. A SIP-enabled
end ystem must be able to act a both a client and a
3.1. RTP
server, as call participants may either generate or
receive calls. For this reason the end system in a
SIP uses the RTP protocol for streaming real-time
IP ba ed environment is called a u er agent erver.
data. The RTP protocol i used to transport data
onnally the user agent respond to requests based
with real-time properties, although RTP cannot
on some human interaction. Unlike a typical c1ient-
guarantee any reliability or ensure real-time
server architecture, both the user agent client and the
delivery. The RTP protocol provide functionality
user agent server have the ability to tenninate calls
that is uited for canying real-time content [14].
[I] and [23].
The RTP protocol as igns timestamp and sequence
A basic SIP call follows the routine outlined in
numbers for multimedia packets. From these the
Figure 2 [10], and a typical SI P message has the
timing order can be restored at playback packet
format shown in Figure 3 [I I] and [12].
reordering can be accomplished and losses can be
detected. The RTP packet header's minimum size is
12 bytes (the fields up to the SSR identifier are
mandatory). Other useful information contained in
the 12-byte RTP packet header includes the payload
62 THE TRANSACTIONS OF THE SA INSTITUTE OF ELECTRICAL ENGINEERS September 2003

type and source identifier [I]. The RTP header was used to simulate the Internet. Figure 6 depicts
format is given in Figure 4. the set-up configuration.

It is important to emphasize that the RTP protocol The simulation program (The Cloud from
does not make provision for resource reservation and www.shunra.com) adjusted certain parameters of the
docs not guarantee any quality-of-service for real- simulated Internet. The adjusted parameters
time services [13]. included the packet loss, jitter and delay.

3.2. RTCP NetXRay was used to capture the network data. A

typical captured packet in hexadecimal format is
The RT P protocol's main function is to provide shown in Packet 1. A C++ program was used to
feedback on the quality of service experienced for a dissect the hexadecimal data, and to calculate the
speci fic real-time stTeam. Control packets Quality of Service (QoS) parameters. These data
containing information on the quality of service are were saved to a file that was processed with a
periodically transmitted from all the participants ofa MATLAB program.
session to all other participants in the session. A
non-intrusive data collector can only collect the 00 dO b7 15 cc e2 00 dO b7 15 cc el 08004500
RTCP packets without the corresponding RTP data 0070 b6 da 00 00 SO 11 99 ce SfaO 65 4a 8faO
packets and must evaluate the quality of service 6549223f223f005c4d2cSI cSOOOc522a
from the RTCP packets [13]. ec d6 be 08 39 Ie J0 e5 60 41 2a 77 a4 79 00 00
00 fd 00 00 ge 20 fJ 64 9f90 00 00 00 00 00 00
23 a5 00 00 00 9a 00 00 00 00 00 00 00 00
All RTP senders generate a sender report. A sender
report contains information useful for media
Packet I.
synchronisation, as well as cumulative counters for
packets and bytes sent. Receivers generate receiver
4.2. Outline of/he Dissecting Procedure
reports for all video and audio sources received.
Information contained in receiver reports includes
The schematic in Figure 7 gives an outline of the
the highest sequence number received, the number
whole dissecting process.
of packets lost, a measure of the inter-arrival jitter
(an estimate of the statistical variance of the RTP
Each packet must be scanned and the protocols in
data inter-arrival time), and timestamps [13]. Figure
the packet identified. From each protocol, the
5 shows the RT P's header formal.
relevant data can be extracted. The first part of the
processing will be the same for each packet, because
the data was derived on an Ethernet LAN, which
4. DATA EXTRACTION
implements the Ethernet protocol (this will be
different for other types of networks).
The first step was to capture the data from the
network. After the data was captured each data
The Ethernet header contains afield that identifies
packet was dis ected and the protocols in the packet
the upper protocol encapsulated in the Ethernet
were identified. The necessary data from each
packet. A value of 800 hex identi fies the IP protocol.
protocol was then extracted.
Evaluating this field can filter all the IP packets.
4.1. et-up and Capturing ofthe Data
The IP protocol field in the IP header identifies the
next upper protocol. For T P, this field has a value
The basic set-up used during the investigation
of 6 hex and for UDP a value of I J hex.
consisted of two computers with IP user agent
installed, connected to a Local Area Network
The destination port field in the transport protocol
(LAN). A third computer with a network sniffer was
header (UDP or TCP) is used to distinguish between
connected to the same LAN. A simulation program
the next upper layers. The SIP mes ages are sent to
port 5060dee in a similar way a HTTP send its data

IOl
o I I I 21
m I2l
31 41 51 61 71 sl 91 01 II 21 31 41 51 61 71 81 91 0 I 11 21 31 41 51 61 71 81 91 01 I
f3l
Y-2IP[X[ CC 1 MI PT I Scoucncc numbcr
Timcstamp
Synchronisation sourcc (SSRC) idcntificr
Contributing sourcc (CSRC) idcntificrs
...

Fig. 4. RTP header structure [131·

September 2003 THE TRANSACTIONS OF THE SA INST1TUTE OF ELECTRlCAL ENGINEERS 63

Ol m m [3l
0[1121314151617181910\11213\41516\7181910\112131415\61718191011
v=21 pI RC 1 PT=SR=200 1 Length
SSRC of packet sender
NTP timestamp, most significant word
NTP timestamp, least significant word
RTP timestamp
sender's packet count
sendcr's octet count
SSRC I (SSRC of first source)
Fraction lost 1 Cumulativc number of packets lost
Extended highest sequence number
Interarrival jitter
Last SR
Delay since last SR (DLSR)
SSRC 2 (SSRC of second source)
...
Profile specific extensions

Fig. 5. RTCP packet [13].

S
Moritoring Program

UA1 UA2

Fig. 6. Quality of Service set up

LID!' port =
Rll' port #

Fig. 7. Proces outline

to port 80dcc ' The RTP and RTCP packets are also
identified by their destination port numbers. The
RTP port numbers are negotiated before the session
starts via IP. Each RTP stream has a
corresponding RTCP stream. The destination port
number of the RTCP stream is the RTP port number
plu one (usually an odd number) [13].
Using Packet I of section 4.\ the process of
decoding the packets will be shown. The decoding
64 THE TRANSACTIONS OF THE SA INSTITUTE OF ELECTRICAL ENGLNEERS
process for each type of packet is very similar with
only minor changes.
4.3. Processing the Ethernet and IP Headers
The first protocol that must be decoded is the
Ethernet protocol [15). Relevant data that can be
extracted includes the destination media access
control (MAC) address (6 bytes), the source MAC
address (6 bytes) and the Ethernet Protocol field (2
bytes). The Ethernet Protocol field is used to
determine the next higher protocol [15).
In Packet I of section 4.1 the destination MAC
address contains the bytes (00 dO b7 15 cc e2), the
source MAC address contains the bytes (00 dO b7 15
cc e I), and the Ethernet Protocol field contains the
bytes (00 80). The destination MAC address can be
computed as 00DOB715CCE2 he x> the source MAC
address as 00DOB715CCE I hex and the Ethernet
Protocol field as 800"ex. The value of 800"ex
indicates that the encapsulated protocol is an IP
packet.
From the [P header [16], the Protocol field (one
byte), IP source address (4 bytes) and IP destination
address (4 bytes) can be extracted. The Protocol
field determines the higher layer protocol being
transported. Only two higher layer protocols will be
considered namely the TCP and UDP protocols. If
the higher layer protocol is a TCP packet, the
Protocol field will have a value of 6 he x> and if it is an
UDP packet a value of I I "ex will be contained [16).
The source address field identi fies the sender of this
datagram. The destination address field identifies
thc ultimate destination of this datagram.
addresses arc written in a format known as the
dotted decimal address format [17], e.g.
143.160.101.74.
For Packet I, the protocol field contains a value of
(I I) and indicates that the next upper protocol is an
UDP packet. The IP source address field (8f aO 65
4a) and the IP destination address field (8f aO 65 49)
can be computed by converting each byte to
decimal. The IP addresses can be converted to the
dotted decimal address format by placing dots after
each byte. The IP source address is computed as
143.160.101.74 and the IP de tination address as
143.160.101.73.
4.4. Decoding of/he rep and UDP Headers
A fter the Ethernet and IP headers have been
processed, and the higher layer protocol has been
identified as the either TCP or UDP protocol, the
packet can be processed further.
Although the packet headers of the two protocols
di ffer, and the two protocols are designed for two
different applications, they contain the same
necessary information. Important fields in the
September 2003
header are the source port (2 bytes) and the
destination port (2 bytes) [18] and [19).
The destination port determines whether the higher
layer protocol is a SIP message, a RTP packet or a
RTCP packet [20). The SIP protocol listens on port
5060 dee for SIP messages. The RTP port numbers
are negotiated before the call starts via SIP. The
RTCP port numbers can be calculated from the
negotiated RTP port numbers.
For the example packet, the source port (22 3t) can
be computed as 8767dee . Tn a similar way the
destination port (22 3t) is also computed as 8767 dee .
4.5. Decoding ofthe SIP Messages
After a SIP message has been identified, the
message can be decoded by simply converting the
hexadecimal values of the bytes of the data portion
of the TCP or UDP packet to the corresponding
ASCII characters. Message 1 is an example of a
decoded SIP message.
INVITE sip:4444@143.160.101.73 SIP/2.0
From: sip:4444@143.160.1OI.74;tag=lc41
To: sip:4444@143.160.101.73
Call-Id: call-979217538-2@143.160.1 0 1.74
Cseq: 1 INVITE
Content-Type: applicationlsdp
Content-Length: 114
Accept-Language: en
Supported: sip-cc, sip-cc-O I, timer
Contact: sip:4444@143.160.1 0 1.74
User-Agent: PingteVO.8.0 (WinNT)
Via: SIP12.0/UDP 143.160.101.74
[P
v=O
o=Pingtel5 51N IP4 143.160.101.74
s=phone-call
c=IN IP4 143.160.101.74
t=00
m=audio 8766 RTP/AVP 0 8
Message I.
The following information can be extracted from the
SIP protocol:
• the IIlltlator of the request:
sip:4444@143.160.101.74;
• the desired recipient of the request:
sip:4444 143.\60.\ 0 1.73;
• the type of media (audio or video) that is
going to be sent: audio;
• the protocol that is going to be used to
transport the real-time data: RTP;
• the port number where the VolP data is
going to be sent (the RTP port number):
8766;
• the type of codec that is going to be used: 0
-G.7! I.
September 2003 THE TRANSACTIONS OF THE SA INSTITUTE OF ELECTRICAL ENGINEERS
4.6. Decoding ofthe RTCP Packets
The call parameters are negotiated with SIP before
the start of the session. During the negotiation the
RTP port numbers are established, and the RTCP
port numbers can be derived from the RTP port
numbers. For Packet 1 of section 4.1 the destination
port number of the UDP header identifies the
example packet as a RTCP packet.
From the RTCP packet the network time protocol
(NTP) timestamp (8 bytes), the sender's packet
count (4 bytes), the sender's octet count (4 bytes),
the fraction of packets lost (l byte), cumulative
number of packets lost (3 bytes), extended highest
sequence number (4 bytes) and inter-arrival jitter (4
bytes) can be extracted [13].
For the example packet, the NTP timestamp (be 08
39 Ic 10 e5 60 41) is computed as 3188209948.066
seconds, the sender's packet count (00 00 00 fd) as
253 dcc , the sender's octet count (00 00 ge 20) as
40480 dcc , the fraction of packets lost (00) and
cumulative number of packets lost (00 00 00) as 0,
the extended highest sequence number (00 00 23 a5)
as 9125 dcc and the inter-arrival jitter (000000 9a) as
154dcc .
4.7. Decoding ofthe RTP Packets
As was mentioned earlier, the RTP protocol is used
to transfer the video or audio or any other real-time
data. The RTP header can be decoded in a similar
way as the RTCP packets. The RTP data are a
specific encoding as for instance G.711. Useful
information that can be extracted from the RTP
protocol includes the payload type and timestamp
[13]. It is however possible to get an estimation of
the quality of service experienced by only inspecting
the RTCP and SIP packets, ignoring the RTP
packets.
5. QUALITY OF SERVICE ESTJMATIONS
The information extracted from the RTCP packets is
used to give an indication of the quality of service
(QoS) experienced during the call.
A typical two-party voice session that is full duplex
consists of two RTP streams. One RTP stream
transports the voice data from the originator of the
call to the recipient, and the other stream transports
the voice data from the recipient to the originator.
Each RTP stream has a corresponding RTCP stream
which provides feedback on the quality of service
experienced.
As only two-party voice sessions were investigated,
the RTCP packets consisted of two parts, a sender
report block and a receiver report block. From each
block, the required data was extracted.
65
The information extracted from the sender report
block refers to the sender of the data, in this case the
participant identified in the IP Source field in the IP
header. Information contained includes the NTP
timestamp, the sender packet count and the sender
octet count.
The data that was received by the receiver and the
quality of reception are conveyed in the receiver
repOlt block. The information contained in the
receiver block refers to the data received by the
receiver indicated in the IP Source field in the IP
header. Information that can be extracted from the
receiver block includes the fraction loss, the
cumulative number of packets lost, the extended
highest sequence number received and the inter-
arrival jitter.
5.1. Formulae for Some of the QoS Parameters
The data extracted from the RTCP packets can be
used to calculate several QoS parameters. Table I
lists a number of such parameters for the sender of
the data, with the equations used to calculate them.
The parameters that can be extracted from the
receiver are summarized in Table 2.
6. RESULTS
With circuit switched networks, it was sufficient to
collect only the start time, the end time, duration, the
originator, and the receiver of a particular call.
When IP networks are used to transfer real-time
data, other information is also needed for the detail
records. Information needed includes the amount of
data that was sent during a call, the type of
information that was sent (HTTP, SIP, H.323, etc.)
the quality of service experienced and the type of
codec that was used.
In this investigation this data has been extracted
from the packet flow of an IP network. Table 3
gives an example of a detail record, with the
parameters extracted or calculated from the
protocols.
Using the equations in Table I and Table 2, various
graphs can also be plotted for the sender and
receiver of an RTP stream. These graphs give more
insight into the QoS experienced during the call.
An example of the possible uses of these graphs is as
follows: A Service Level Agreement can be
determined beforehand. Whcn the sender violates a
certain service level, for instance by overloading the
network, the user can be fined according to these
graphs. Also, when the receiver experiences a
service whose quality does not conform to the
agreed service level, the network provider can be
liable for a discount, which can be calculated from
the information on the graphs.
66 THE TRA SA TIONS OF THE SA INSTITUTE OF ELECTRICAL ENGI EERS September 2003

Figure 8 gives examples of graphs obtained from rate per interval. The Interval Payload Data Rate
combining sender statistics of one participant with and Throughput Rate plots the data rate (in octets/s)
receiver statistics of another participant during a per interval for the data send (Payload data) and the
call. data received at the receiver (Throughput Data).

The explanation of the different sections in this
graph is as follows: The umulative Packets Sent
and -Received ection shows the difference in the
number of packets sent from the sender and the
nlllnber of packets received by the receiver for a
time interval. The umulative Packet Count and -
Loss section shows the number of packets that was
sent from the sender, and the number of packets that
the receiver did not receive.
The Interval Packet Send and -Receive Rate plots
the rate per interval at which the packets were sent
and received. The Interval Packet Send and -Loss
Rate plots the loss rate per interval against the send
For the example graphs in Figure 8, the network was
parameterised to simulate a random packet loss of
10% (with The Cloud). The packet loss of 10% is
clearly depicted in Figure 8. From this graph, the
network operator can evaluate the QoS experienced
during the call made.
In Figure 9 the cases of 0%, 10%, 30% and 60%
packet loss are compared.
In Figure 10, the situations for 0, 3 and 60 ms of
inter-arrival jitter are compared.

Table I RTCP sender GoS parameters

QoS parameter Equation

Interval Octet Count
Interval Packet Count
Interval Average Payload Data Rate
Interval Average Packet Rate
Interval Average Payload Size
sender's octect count z - sender's octet count l
sender's packet countz - sender's packet count,
(sender's octet countz-sender's octet count l)
(NTP Timcstampz- NTP Timestamp,)
(sender's packet counh-sender's packet count,)
(NTP Timestampz- NTP TimestampI)
Interval Average Payload Data Rate
Interval Average Packet Rate

Where parameterj with j in [1,2] denotes the values extracted I'TOm two RTCP packets. The packet with the
highest NTP Timestamp value denotes the case wherc j = 2, and the packet with the lowest NTP Timestamp
where j = I.

Table 2 RTCP receiver oS arameters

parameter Equation
Packets Received per ([Extended_highest_sequence_numberz - Extended_highest_sequence_numberd -
Interval rCumulative number of packets lostz - Cumulative number of packets 10Slin
Interval Received Packet Packets Received per Interval
Rate (NTP Timeslampz - NTP Timestampl)
Interval Packet Loss Cumulative number of packets lostz - Cumulative number of paekels lost l
Interval Packet Loss Rate Interval Packet Loss
(NTP Timestampz - NTP Timestampl)
Interval Apparent (Packcts_Received er_lntervaIRx) x (Interval_Average_Payload_SizeTx)
Throughput Available (Note I)
Interval Apparent
Available Throughput (I nterval_Received_Packet_ RateRx) x (Interval_Average_Payload_SizeTX)
Rate (Note I)
Interval Jilter (s) Jittcr x RTPtimestamp unit
Interval Fraction Loss (Cumulative number of packets lostz - Cumulativc number of packets lost l )
(btendcd hil!hest sCQuence numberz - Extended highest sequence numberl)
Intcrval Fraction Loss Interval Fraction Loss
Ratc (NTP Timcstampz NTP TimestampI)

Notc I: parameter" denotes the parameter of the sender (obtained from the RTCP sender block where the source
IP address equals that of the sender) and parameter", that of the receiver (obtained from the RT P receiver block
where the source IP address equals that of the receiver).
September 2003 THE TRANSACTIONS OF THE SA INSTITUTE OF ELECTRI AL ENGINEERS 67

Table 3 Typical detail record

Detail Record Field: Value: Protocol Protocol Field

Idcntity of recipient equipment 143.160.11.160 IP IP destination address
00047697C5A 7hcx Ethernet MAC destination address
Identity of sender equipment 143.160.11.163 IP IP source address
00DOB715CCE Ihex Ethernet MAC source address
Identity of Callee sip:143.160.11.160 SIP To
Identity of Caller sip: 143.160.11.163 SIP From
Type of Media Audio SIP m (SDP description in SIP)
Codec Type G.7ll SIP m (SOP description in SIP)
Time of Call 10/27/2001; 07:26:26 PM SIP Note I
Duration of Call 00:03:11 SIP Note I
Ring time 00:00:07 SIP Note 1
Amount of data sent (Packets) 3622 RTCP Sender's packet count
Amount of data sent (bytes) 86928 RTCP Sender's octet count
Amount of data received (Packets) 3622 RTCP Note 2

Note I: This data can be calculated by observing when the 180 (ring time), ACK (call start), and BYE (call end)
messages of the SI P protocol are sent [22].
Note 2: This field is a cumulative count of the Packets Received per Interval parameter of Table I.

o
Cumulative Packets Sent and -Received Cumulative Packet Count and -Loss
8000 8000·
I

~
<Il
6000 I
<Il

~
6000
~-m~
II
4000 4000
'" 2000 1 '" 2000 1 i
1
0- 0-
~ I 0

0.,...· -
~e;
L - -----"L- ---',
o el *--~ • • • • I· !
o 50 100 150 200 250 o ~ 100 1~ 200 ~o
Elapsed Time (s) Elapsed Time (s)

Interval Packet Send and -Receive Rate tnterval Packet Send and -Loss Rate
40 40

30 30 th h';~~
if
~ ~
~ 20 ]1 20 I
I \.1

.. . . I
0

'"
0- 10 II' i
'"
0- 10
I ;
o
o 50
I
100 150 200 250
0'
0
el

50
0

100
• 0

150
I
200
0

250
Elapsed Time (s) Elapsed Time (s)

Interval Payload Data Rate and Throughput Rate.

1000

}~ I
~
Q)
I
500 llJr."
., \ 1 I.tO
Scnder Information
Receiver Information
ou I

0'
o 50 100 150 200 250
Elapsed Time (s)

Fig. 8. omparing sender and receiver statistics (10% packet loss).

68 THE TRANSACTIONS OF THE SA INSTITUTE OF ELECTRICAL ENGINEERS September 200:

Cumulative Octet Count Cumulative Packet Count

8000

2.5
6000 - -- f-
V
'"
8
J£ 1.5 ~ 4000 V/
I:.
2000 /
0.5

0
0 100 200 300 400
~ 100 200 300 400
Elapsed Time (s) Elapsed Time (s)

Cumulative Packets Lost Cumulative Packets Received

4000 4000

/
3000 - ~ 3000

~ 2000
,- ~. ~ 2000
a. a.
1000
.// ~ - 1000
(f
,;

-
0
100 200 300 400 0 100 200 300 400
Elapsed Time (s) Elapsed Time (s)

0% packet loss
10% packet loss
30% packet loss
60% packet loss

Fig. 9. Comparison of 0%, 10%,30% and 60% packet loss

Interval Jitter - 0 ms Interval Jitter - 3 ms

0.012

0.01
3.5

0.008
~
iii 0.006
~
0.004

0.002

0
0 50 100 150 200 50 100 150 200 250
Elapsed Time (5) Elapsed Time (5)

Interval Jitter· 60 ms
0.05

0.04

'"

r
iii 0.03
~
0.02

0.01
o 50 100 150 200 250
Elapsed Time (5)

Fig. 10. omparison of Oms, 3ms and 60 ms of jitter

September 2003 THE TRANSACTIONS OF THE SA INSTITUTE OF ELECTRlCAL ENGINEERS
The means of the jitter for the three situations are
respectively 2.4 ms, 2.6 ms and 30.5 ms. The reason
why the mean of the jitter experienced for the case
when the jitter parameter was set to 0 ms with The
Cloud was 2.4 ms, is that this value is the inherent
jitter of the Ethernet LAN and the programs used.
The jitter increased when the jitter parameter was set
to 3 ms. The jitter increased further when the jitter
parameter was set to 60 ms, but didn't reach 60 ms.
A reason for this can be that the program used to
simulate the jitter reached its maximum for the jitter.
7. CONCLUSION
Currently two major efforts for IP telephony exist.
The one is H.323 and the other is SIP. SIP is a very
flexible protocol and has an uncomplicated
implementation, making it a good candidate for the
de-facto V 0] P standard [21].
The SIP protocol is used for signalling and the RTP
protocol for transportation of the data for a
multimedia session. At this stage, the SIP protocol
lacks a billing infrastructure [I]. This paper's main
aim was to see what data could be extracted from the
packet flow of a VoIP session, to derive a method
for the extraction purpose, and to depict the QoS
experienced during a call, for the purposes of
compiling detail records. Possible uses of the detail
records include billing, fraud management and
network planning.
REFERENCES
[I] H. Schulzrinne and J. Rosenberg, "Internet
telephony: architecture and protocols - an ]ETF
perspective," Computer Networks, no. 31, pp.
237-255, 1999.
[2] McLain Computer Consultants, What is VolP.
[Web:]
http://www.techcorrect.com/TechWrite/Write02.
html [Date of access: 7 Nov. 2001].
[3] M. Hassan, A Nayandoro and M. Atiquzzaman,
"Internet telephony: services, technical
challenges, and products," IEEE
Communications Magazine, vol. 4, no. 34, pp. 96
- 103,2000.
[4] Anon, Voice over IP (VoIP). [Web:]
http://www.protocols.com/papers/voip.htm [Date
of access: 7 Nov. 2001].
[5] Anon, Voice over IP technology. [Web:]
http://www.alliancedatacom.com/voice-overi p-
tutorial.htm [Date of access: 7 Nov. 2001].
[6] Insight, IP billing: moving beyond Telecom's
time and distance billing model 1999-2004.
[Web:] http://www.insight-corp.com/ipbill.html
[Date of access: 7 Nov. 200 I].
69
[7] P. Loshin, TCPIIP clearly explained, 2 nd ed.
Boston: AP Professional. 1997.
[8] H. Schulzrinne, Internet technical resources.
[Web:]
http://www.cs.columbia.edu/~hgslinternet/
[Date of access: 8 Nov. 2001]
[9] W. Stallings. Data and computer
communications, 5th ed. New Jersey: Prentice-
Hall, 1997.
[10] P. Tiilikainen, SIP (RFC 2543), an
implementation for Marratech Pro. MSc.
Thesis, Lulea University of Technology, Lulea,
2000.
[II] H. Schulzrinne, The Session Initiation
Protocol (SIP). [Web:]
http://www.cs.columbia.edu/~hgs/teaching/ais/sli
des/sip2.pdf [Date of access: 5 Jun. 200 I].
[12] M. Handley and V. Jacobson, SDP: Session
Description Protocol. RFC 2327. 1998.
[13] H. Schulzrinne, S. Casner, E. Frederick and V.
Jacobson, RTP: a transport protocol for real-
time applications. RFC 1889. 1996
[14] H. Schulzrinne, Some Frequently Asked
Questions about RTP. [Web:]
http://www.cs.columbia.edu/~hgs/rtp/faq.html
[Date of access: 10 Nov. 2001].
[15] R. Haden, Ethernet Basics. [Web:]
http://www.rware.demon.co.uklethemet.htm
[Date of access: 8 Nov. 2001].
[16] Information Science Institute University of
Southern California, Internet Protocol. RFC
791. 1981.
[17] D. Hoggan, 2000. The Internet book:
Introduction and reference. [Web:]
http://www.theinternetbook.net/[Date of access:
8 Nov. 2001], 2000
[18] J. Postel, Transmission Control Protocol. RFC
793, 1981.
[19] J. Postel, User datagram protocol. RFC 768,
1980.
[20] A. llkov, (alen.ilkov@cacheflow.com). RTP
and RTCP port numbers. [E-mail to:] Versfeld,
D.J.J. (eeidjjv@puknet.puk.ac.za) 27 Mar.
2001.
[21] I. Dalgic and H. Fang, Comparison of H.323
and SIP for IP Telephony signalling. [Web:]
http://www.cS.coIumbia.edu/~hgs/papers/others/
Dalg9909_Comparison. pdf [Date of access: 8.
Nov. 2001].
[22] C.U. Eckel, (eckelcu@cisco.com) 2001. Call
Detail Records for SIP. [E-mail to:] Versfeld,
D.J.J. (eeidjjv@puknet.puk.ac.za) Jun. II.
[23] M. Handley, H. Schulzrinne, E. Schooler and J
Rosenberg, SIP: Session Initiation Protocol.
Internet Draft RFC 2543,2001.