ELEKTROTEHNIŠKI VESTNIK 79(3): 105-110, 2012 
ENGLISH EDITION 
Structuring the RCS services on the IMS application layer                      
Part II: Server traffic and configuration comparison  
Valerij Grašič 
1
, Andrej Kos 
2
 
1  
Iskratel d.o.o., Ljubljanska c. 24 a, 4000 Kranj, Slovenia   
2
 Univerza v Ljubljani, Fakulteta za elektrotehniko, Tržaška cesta 25, 1000 Ljubljana, Slovenia 
E-mail: valerij.grasic@iskratel.si 
 
Abstract. This is the second of our two-part paper on structuring the application layer. In the first paper we  
defined the description and comparison parameters for the application-layer configurations. In the second paper 
we analyse the impact of each of the services on the server traffic using a real test bed. We find the traffic impact 
on S-CSCF to be in some cases twice the traffic of basic voice call. Configurations of four different scenarios 
using the cost function and the parameters are compared. Using the cost function based on the server traffic, the 
configuration with all the services residing on each AS is shown to be most efficient. We also prove that for each 
scenario, the traffic on S-CSCF and on the entire configuration for all the analysed configurations is always the 
same, safe for the traffic on each of ASs. 
 
Keywords: RCS, service placement, service triggering, IMS, application server 
 
 
1 INTRODUCTION 
The challenge being faced with in structuring the RCS 
(Rich Communication Suite) services on the IMS (IP 
Multimedia Subsystem) [1] application layer is how to 
place a set of services and users on the RCS application 
servers in a cost-efficient way.  
 In the first part of our paper paper [2] we described 
and compared configuration parameters to be used in 
structuring the RCS services on the IMS application 
layer.  
 In the second part of our paper, we analyse the traffic 
impact of five services on the server traffic. This is done 
by using a real test bed. Based on our analysis results, a 
traffic model enabling service placement for servers is 
made. By using the model, the configurations for the 
selected scenarios using the parameters specified in [2] 
are compared. By optimising the process and using the 
cost function based on the server traffic, a cost-efficient 
service placement is proposed. 
 
 
2 A MODEL OF THE SERVICE IMPACT ON THE 
SERVER TRAFFIC  
2.1 Test-bed description  
In our testing, the test-bed shown in Fig. 1 was used. It 
consists of a UPSF (User Profile Server Function) 
database, CSCF (Call Session Control Function) 
compact server (C-IMS, Compact-IMS) performing the 
P-CSCF (Proxy-CSCF), I-CSCF (Interrogating-CSCF) 
and S-CSCF functions, three application servers (AS1, 
AS2, AS3), presence server (PS) and users from one to 
N (UE, User Equipment).  
 The Iskratel SI3000 software is running on the CSCF 
compact server and on the application servers. 
Characteristics of each of the servers and UPSF are: HP 
Compaq Intel Core 2 CPU 6300, 1.86 GHz processor, 
Pentium 4, 1 GB RAM with Linux i686 (Carrier Grade 
Linux 4.0). PS is MobiCents [3]. Connection of each of 
the servers is 100 Mbit/s FD and they are all connected 
to the 3Com Switch 3300 XM 10/100 24-port switch.  
The Mercuro Bronze [4] and Boghe [5] terminals and 
the SIPp traffic generator [6] are used as users (UE, 
User Equipment). 
 
Figure 1. The test-bed setup 
 
Received June 23, 2012 
Accepted September 12, 2012 
AS1 
UE-1 
UE-N 
 UPSF 
S/P/I-CSCF 
AS2 AS3 
UE-2 
UE-3 
 PS 

106 GRAŠIČ, KOS 
2.2 Characteristics of analysing the service impact 
on the traffic 
We first analysed a set of five services placed into an 
environment with three application servers. The services 
were placed on S-CSCF and on one or two ASs. In case 
of two ASs only the basic call and IM are possible. We 
analysed the compact version of CSCF, as we were 
interested only in the signalling traffic and impact of the 
service traffic on S-CSCF and ASs. In our analysis the 
traffic was divided into individual segments, i.e. the 
traffic of each service was analysed separately. 
 Other simplifications and particularities of our 
analysis are: 
 For the basic call (BC),  TIP/OIP services are 
assumed to be used. 
 For the basic voice call, the minimum number of 
messages and additional options (PRACK, 183) 
are taken into account. 
 For CDIV only CFU is analysed. 
 When analysing the IM service, the page mode 
is taken into account, by using the SIP 
MESSAGE method. 
 For subscribing, the presence service and 
registration are taken into account.  
 For the presence service, both possibilities for 
PS (PS is outside AS, PS is part of AS) are taken 
into account in the model.  
2.3 Detailed analysis of the traffic characteristics  
2.3.1 Basic call 
In our basic voice-call traffic model, the call with no 
additional options is used. For the basic voice call with 
the PRACK additional option, there are two extra sets 
for sending the PRACK messages to the basic call (BC). 
Fig. 2 shows the basic call on S-CSCF using the 
additional option of exchanging PRACK and 183.  
2.3.1 CDIV 
In case of CDIV (CDIV-CFU), the messages are the 
same as to those of the basic voice call, except that for 
CDIV from AS1 towards the user the additional 
message 181 (Call Forwarding) is sent, to notify that the 
communication has been forwarded. The traffic model 
is defined as the difference to the traffic model for the 
basic call (defined as BC). 
2.3.2 CAT 
When using CAT, the messages are the same as those of 
the basic voice call. The difference is that for CAT the 
call is directed from AS1 toward S-CSCF and user B. 
When the information about ringing is received from 
user B, the tone control as desired by the user is 
requested by MRF (Media Resource Function). The 
traffic model is defined as the difference to the traffic 
model for the basic call (defined as BC). When using   
S-CSCF, additional INVITE is sent from S-CSCF to 
MRF. When using S-CSCF and AS1, an additional 
INVITE is sent from AS1 to S-CSCF and further by the 
H.248 protocol to MS (Media Server).  
 
Figure 2. Basic voice call on S-CSCF with an additional 
option for exchanging PRACK and 183 
 
2.3.3 IM 
When using IM, the  MESSAGE is sent. It is confirmed 
by 200 on user B. Fig. 3 shows an example of IM 
execution for the case of S-CSCF, AS1 and AS2.     
 
Figure 3. IM (page mode) between user A, S-CSCF, AS1, 
AS2 and user B   
 
2.3.4 Presence 
User A (the source of presence) publishes each state 
change with the PUBLISH message and the event 
package Event: presence in case of presence. The 
message goes from S-CSCF to AS1 and PS. Each user 
B (watcher) is informed about the state change by a 
NOTIFY message and the event package Event: 
presence. The message goes from PS, AS1, and           
S-CSCF to user B. Fig. 4 shows the message exchange 
at the interface between S-CSCF and AS (which 
contains PS) for the two-watcher case. The presence 
source sends PUBLISH, which is confirmed by 200. 

STRUCTURING THE RCS SERVICES ON THE IMS APPLICATION LAYER PART II: SERVER TRAFFIC AND … 107  
AS1 (PS) then sends two messages NOTIFY, which are 
confirmed by 200. To analyse the traffic, PUBLISH and 
NOTIFY must be taken into account. The traffic due 
NOTIFY depends on the number of the watchers (W). 
 
 
Figure 4. Publishing the states of the presence service between 
S-CSCF and AS (which includes also PS), when there are two 
users subscribed on receiving information on publish  
2.3.5 Registration 
To register, the REGISTER message is sent to S-CSCF. 
It is followed by authentication to UPSF with the 
MAR/MAA (Multimedia Auth Request/Answer) 
message and is confirmed by 401. In the second part of 
registration another REGISTER is sent. It is followed 
by the exchange of SAR/SAA (Server Assignment 
Request/Answer) and confirmed by 200. To re-register 
and de-register, the procedure is the same as for 
registration, safe for confirmation which is made only 
by 200, and there is no access to UPSF. The registration 
procedure in shown in Fig. 5. 
 
 
Figure 5. User registration from S-CSCF (REGISTER, 401, 
REGISTER, 200) to UPSF (MAR, MAA, SAR, SAA) and 
further to AS (REGISTER, 200), where there are three service 
groups (G=3)  
 
When using AS1, REGISTER is sent to AS1 and is 
confirmed by 200. There are as many requirements for 
registration as there are iFC records in the database for 
AS. In Fig. 5, there are three service groups (G=3) on 
AS which makes three iFC records in the UPSF 
database. Such an example is configuration K1 
described in [2], where the first iFC record is for 
INVITE (TIP/OIP, CDIV, CAT), the second for 
MESSAGE (IM) and the third for PUBLISH and 
SUBSCRIBE (Presence).   
2.3.6 Subscription  
To subscribe the user sends the SUBSCRIBE message. 
Subscribing for the presence service consists of 
subscribing to the state changes with the event package 
Event: presence and subscribing to receiving the 
information about watchers with the event package 
Event: presence.winfo. To register, the user subscribes 
to the registration state with the event package Event: 
reg. Fig. 6 shows subscribing with the SUBSCRIBE 
message for the event package Event: presence. 
Subscribing is made on S-CSCF, AS1 and external PS. 
SUBSCRIBE is confirmed by 200. NOTIFY then sends 
the information about the watchers. SUBSCRIBE is sent 
to each subscriber present in the contacts. 
 
 
Figure 6. Subscribing using SUBSCRIBE for Event: presence 
which is sent for each user in the contacts (from S-CSCF, 
AS1, to external PS) 
 
The traffic is analysed with regard to SUBSCRIBE and 
NOTIFY. In case of registration and event package 
Event: reg the traffic is only on S-CSCF. In case of 
subscribing for presence and event package Event: 
presence.winfo user A sends a request for subscribing. 
Subscribing is confirmed by 200 and then by NOTIFY. 
In case of subscribing for presence and event package 
Event: presence, user A sends one request for each user 
B that is present in the contacts (C: number of contacts). 
Subscribing is confirmed by 200 and then by NOTIFY. 
2.4 Server impact on the traffic from given 
services 
2.4.1 Traffic with only S-CSCF in the chain 
Table 1. The number of messages with only S-CSCF in the 
chain (on S-CSCF) (S: number of messages) 
Seja S (to) S (from) S 
REG 4 4 8 
de-REG, re-REG 1 1 2 
BC 6 7 13 
BC+183 
BC+1 
BC+1 BC+2 
BC+PRACK 
BC+4 
BC+4 BC+8 
BC+183+ PRACK 
11 
BC+5 
12 
BC+5 
23 
BC+10 
CAT, CDIV BC BC+1 BC+1 
IM 1 1 2 
 
Our analysis of the traffic for the services executed only 
on S-CSCF is given in Table 1. For each service, the 
number of the messages to and from the servers and the 
total number of all the messages are given. BC is the 
number of the messages for the basic call. The basic call 
is further expanded by sending PRACK and 183 as an 
additional option. 
 It is seen that the traffic impact due to registration (8) 
is more than half the basic-call (13) traffic, and that the 

108 GRAŠIČ, KOS 
basic-call traffic with additional options (PRACK, 183) 
is twice (26) the traffic with no additional options (13). 
 
2.4.2 Traffic with S-CSCF and one AS in the chain 
Table 2: The number of messages where there are S-CSCF 
and AS1 in the chain (S: number of messages, G: number of 
groups - number of iFC records for user for AS, A: number of 
AS on which there are services for user, C: number of 
contacts) 
 
Service Server S (to) S (from) S 
REG S-CSCF 4+1*G*A 4+1*G*A 8+2*G*A 
 AS1 
1*G 
1*G 2*G 
re-REG  
de-REG 
S-CSCF 
1 
1 2+2*G*A 
 AS1 
1*G 
1*G 2*G 
SUBS S-CSCF 
6+4*C*A 
6+4*C*A  12+8*C*A 
 
AS1 brez 
PS 
4+4*C 
4+4*C 8+8*C 
 AS1 + PS 
2+2*C 
2+2*C 4+4*C 
BC S-CSCF 
13 
13 26 
 AS1 
6 
7 13 
BC+183 S-CSCF 
BC+2 
BC+2 BC+4 
 AS1 
BC+1 
BC+1 BC+2 
BC+ 
PRACK 
S-CSCF 
BC+8 
BC+8 BC+16 
 AS1 
BC+4 
BC+4 BC+8 
CDIV S-CSCF 
14 
BC+1 
14 
BC+1 
28 
BC+2 
 AS1 
6 
BC 
8 
BC+1 
14 
BC+1 
CAT S-CSCF 
BC+1 
BC+1 BC+2 
 AS1 
BC 
BC+1 BC+1 
IM S-CSCF 
4 
4 8 
 AS1 
2 
2 4 
Pres S-CSCF 
2+2*W 
2+2*W 4+4*W 
 
AS1 brez 
PS 
2+2*W 
2+2*W 4+4*W 
 AS1+PS 
1+1*W 
1+1*W 2+2*W 
 
For the services executed on S-CSCF and on one AS 
(AS1), the traffic analysis is shown in Table 2. BC is the 
number of messages for the basic call, C is the number 
of contacts in the contact, A the number of ASs on 
which there are services for the user, and G the number 
of groups for each AS (number of iFC records for the 
user). In addition to the messages for S-CSCF (total 8), 
pairs of the messages (REGISTER, 200) are also taken 
into account for each record iFC (G: the number of 
service groups), for each of the application servers (A: 
number of AS) and for registration. 
 The analysis shows that the traffic on S-CSCF due to 
IM (8) can be one-third of the traffic for the basic call 
with no additional options (26). The traffic due to both 
subscribing and registration (10+20=30) is higher than 
the traffic for the basic call (26). The traffic for the basic 
call with additional options (PRACK, 183) is almost 
twice (BC+20) the traffic for the basic call with no 
additional options (BC=26). It is seen that the impact of 
the traffic services based on the voice call (CDIV, 
CAT), is similar to the impact of the basic voice-call 
(BC). 
 The traffic due to the presence can soon produce 
more traffic than the basic call. If there are five 
watchers, which means that on S-CSCF and AS1 there 
are 24 messages (4+4*5), on S-CSCF it is almost the 
same as for the basic call (26) and twice that on AS1 
(13). In case of eight watchers, the traffic on S-CSCF 
(4+4*8=36) due to the presence is the same as the 
traffic for the basic call in case of two ASs (37). 
2.4.3 Traffic with S-CSCF and two ASs in the chain 
Table 3. The number of messages if there are S-CSCF, AS1 
and AS2 in the chain (S: number of messages) 
Session Server S (to) S (from) S  
BC 
S-CSCF 19 
18 37 
 
AS1+AS2 11 
13 24 
BC+183  
S-CSCF BC+3 
BC+3 BC+6 
 
AS1+AS2 BC+2 
BC+2 BC+4 
BC+PRACK 
S-CSCF BC+12 
BC+12 BC+24 
 
AS1+AS2 BC+8 
BC+8 BC+16 
IM 
S-CSCF 6 
6 12 
 
AS1+AS2 4 
4 8 
 
Table 3 shows the traffic when the services are executed 
on S-CSCF and two ASs (AS1, AS2). It is also shown 
that the number of messages on S-CSCF (BC+30) for 
the basic call with additional options (PRACK, 183) is 
almost twice the traffic for the basic call with no 
additional options (BC=37). The traffic for IM in case 
of two ASs in the chain (12) is almost the same as the 
traffic for the basic call if there is only S-CSCF (13) in 
the chain. In case of the basic call, each server in the 
chain doubles the traffic (S-CSCF: 13, one AS: 26, two 
ASs: 37). 
 
3 CONFIGURATION COMPARISON AND 
OPTIMAL CONFIGURATION SELECTION 
The various configurations [2] were compared by using 
the time parameters in a real environment. A simulated 
comparison using the cost function and description 
parameters [2] was also performed. Our emphasis was 
laid on on the server traffic. Scenarios were compared 
with the most basic RCS services, i.e. the basic voice 
call with no additional options (OIP/TIP) and IM, plus 
registration.  
3.1 Time-parameters comparison  
To compare the time parameters given in Table 4, we 
performed 1.000 measurements with 4 to 12 users 
(using SIPp). Besides the time parameters (given in ms 
with a standard deviation) defined in [2], two other time 
parameters were also measured. The first is the delay 
between sending INVITE and receiving 100 (on user 
A), and the second is the delay at session connection 

STRUCTURING THE RCS SERVICES ON THE IMS APPLICATION LAYER PART II: SERVER TRAFFIC AND … 109  
between sending 200 and receiving ACK (on user B). 
For the basic voice call and IM, the session is chained 
across two ASs for K1-K4. 
 
Table 4. Comparison of the time parameters (in ms) 
Parameter Start-stop K0 Stdv K1-K4 Stdv 
SRD 
INVITE-180 72 1 
316 12 
INVITE-100 
INVITE-100 14 11 
10 2 
 200-ACK 
200-ACK 20 0 
84 7 
SDD 
BYE-200 19 1 
11 3 
SMD 
MESS-200 54 0 
313 13  
RRD1 
REG-401 56 1 
55 9 
RRD2 
REG-200 95 7 
101 14 
RRD 
REG-200 148 18 
152 26 
re-REG 
REG-200 78 13 
66 5 
de-REG 
REG-200 100 14 
115 14 
3.2 Selected scenarios of the given configurations 
Table 5. Scenarios used to compare the different 
configurations  (number of changes for a busy hour) 
Scenario BC IM Reg Name of scenario 
SC1 4 8 1 Avg 
SC2 4 12 1 AvgIM 
SC3 2 2 4 MinReg 
SC4 4 1 - Bc 
 
Four scenarios were used with the traffic data for the 
busy hour (see Table 5). Four voice calls were assumed 
for the basic call (0.1 Erl), 1-12 SMS for IM (according 
to the results given in [4]), and 0-4 registrations. Ten 
measurements were simulated for 120 to 1.200 users. 
3.3  The cost function  
 
Figure 7. Cost function for SC1(Avg) (in 1.000) as a function 
of the number of users (optimal choice: K1) 
 
Our calculation of the cost function (C1) was based on 
the traffic on the servers. C1 is the sum of the traffic on 
S-CSCF (TS) and the maximum traffic on all ASs 
(TASmax) for the busy hour; C1=TS+TASmax. 
 Fig. 7 shows C1 (the number of the messages in the 
busy hour in 1.000) for SC1 (Avg) as a function of the 
number of users. As seen, the function is linear. C1 is 
minimal for K1 and a little less for K4. The ratio C1 
between K2 and K1, and C1 between K3 and K1 is 
1.14, and between K4 and K1 it is 1.04. The same 
applies for C1 in case of SC3 (MinReg), given in Fig. 8. 
In this case, C1 is minimal for K1 as well as for K4. The 
ratio of C1 for K2 and K3 remains the same (1.14). The 
difference in case of K1 for 1.200 subscribers is the 
value of C1 (194.400 signals for SC1 against 135.600 
for SC3). 
 
Figure 8. Cost function for SC3 (MinReg) (in 1.000) as a 
function of the number of users (efficient choice: K1, K4) 
 
3.4 Configuration comparison using description 
parameters  
Table 6. Comparison using the description parameters for SC1 
(the parameters that vary among the configurations are 
shaded) 
Parameter K0 K1 K2 K3 K4 
NUTS 
42 134 134 
134 134 
NUTC 
42 218 218 
218 218 
NUTASmax 
0 28 50 
50 34 
NUTASavg 
0 28 28 
28 28 
TASmm 
- 1 - 
- 1.36 
NSSRD 
1 4.39 4.39 
4.39 4.39 
NSTASavg 
0 0.21 0.21 
0.21 0.21 
NSTASmax 
0 0.21 0.37 
0.37 0.25 
NSTASall 
0 1.63 1.63 
1.63 1.63 
 
Table 7. Normed traffic on the user on the S-CSCF (NUTS), 
configuration (NUTC) and maximally loaded AS (TASmax) 
(the efficient choices are shaded)  
SC K0 K1 K2 K3 K4 
SC1 
42 134/218/28 134/218/50 134/218/50 134/218/34 
SC2 
46 158/258/33 158/258/50 
158/258/50 158/258/50 
SC3 
47 97/145/16 97/145/32 
97/145/32 97/145/16 
SC4 
27 80/132/17 80/132/48 
80/132/48 80/132/24 
 
The configurations for SC1 are compared (see Table 6). 
These are normed data on the user. The traffic on         
S-CSCF (NUTS), on the configuration (NUTC) and 
average traffic on AS (NUTASavg) for all the 
configurations (K1-K4) is the same. The delay ratio on 
the INVITE path (NSSRD) is 4.39. AS is loaded on 
average by a factor 0.21 with regard to S-CSCF 
(NSTASavg). The differences are at the maximum 
traffic on AS (NUTAsmax) and for the traffic ratio 
between ASs (TASmm). 

110 GRAŠIČ, KOS 
 In Table 7, configurations of each of the four 
scenarios are compared. For K0, NUTS=NUTC. The 
efficient choices are shaded. In all the cases, the most 
efficient choice is K1. The efficient choice for SC3 is 
also K4. K4 for SC2, however, means also TASmax. 
3.5 Service placement proposal  
We assume all the ASs to have the same traffic capacity 
(TASmax), safe for S-CSCF whose capacity is greater. 
It can be seen that the traffic on S-CSCF (TS) and on 
the entire configuration (TC) is the same for the given 
scenario. The main difference is in different traffics on 
each AS (TASmax, TASmm). 
 The most efficient configuration in terms of C1 is 
K1. It is scalable and is efficient also for a greater 
number of users. The condition is that on every AS the 
number of the users must be the same and that the 
traffic capacity of AS regarding the S-CSCF is 
appropriate. According to Table 6, the traffic ratio 
between AS with the maximum traffic and the traffic on 
S-CSCF (NSTASmax) is 0.21 for K1 (in general it 
varies between 0.21 and 0.37).   
 Assuming the baseline scenario to be SC1 and the 
basic (efficient) configuration K1, other scenarios and 
configurations are compared according to SC1 for K1. 
The relative ratio is shown in Table 8. From K1 to K4 
the traffic ratio at S-CSCF is from 0.60 to 1.18, and for 
the entire configuration it is from 0.99 to 1.93. For 
different scenarios and thus for the minimum and 
maximum traffic, the deviation factor is almost 2 for 
both cases. The same applies for the maximum traffic 
on AS. The traffic fluctuation on AS (TASmax) is 
shown for the traffic on S-CSCF (TS) for different 
scenarios. For K1 the traffic fluctuation is in the range 
from 0.12 to 0.37. 
 
Table 8. The relative ratio between the traffic on S-CSCF (ts), 
configuration (tc) and AS with the maximum traffic (tmax) 
and the traffic on S-CSCF (ts) in case of SC1 for K1 (the 
lowest values are shaded) 
 K0 K1-K4 K1 K2 K3 K4 
 ts ts tc tmax tmax tmax tmax 
SC1 0.31 1.00 1.63 
0.21 0.37 0.37 0.25 
SC2 0.34 
1.18 1.93 
0.25 0.37 0.37 0.37 
SC3 0.35 
0.72 1.08 
0.12 0.24 0.24 0.12 
SC4 0.20 
0.60 0.99 
0.13 0.36 0.36 0.18 
 
In Table 8 it is shown that configuration K4 is optimal, 
too. Its advantage are its voice-based services which are 
separated (AS1, AS2) from the RCS-based services 
(AS3). If there is no scenario SC2 (with the maximum 
number of SMSs/MMSs), the maximum traffic on AS 
for K4 (0.25) is by less than 20% higher than the traffic 
on AS for K1 (0.21). 
 
4 CONCLUSION 
In the second part of our paper on structuring the 
application layer we propose a model of the service 
impact on the server traffic. The presented 
configurations are compared using the cost function and 
parameters for four different behavior scenarios on the 
basis of which the service placement is proposed. 
 Our analysis of the service impact on ther server 
shows that some of the traffic impacts on S-CSCF can 
be almost twice the impact of the basic call when no 
additional options are used. The results of our analysis 
of the configurations for the four scenarios using the 
basic call, IM and registration prove that the total traffic 
for S-CSCF and the entire configuration for each 
scenario is the same, different for the traffic for each of 
ASs. The traffic on ASs is an important data when 
calculating the cost function. This impose the dilemma 
of how the cost function should be upgraded. 
 The most efficient configuration is K1 with all the 
services located on each of the application servers. The 
question to be answered is in what context (traffic 
deviations) and for which scenarios configuration K4 is 
optimal. 
 The above dilemmas will be dealt with in our future 
research supported by simulations and measurements 
made on a real test bed. Our work will involve all the 
analysed services and the various scenarios for the user 
behavior and services and for improvement of the cost 
functions. 
REFERENCES 
[1] G. Camarilla, M.A. Garcia-Martin, The 3G IP Multimedia 
Subsystem (IMS):Merging the Internet and the Cellular Worlds, 
Second Edition, John Wiley & Sons Ltd, 2006. 
[2] V. Grašič, A. Kos, Structuring the RCS services on the IMS 
application layer Part I: Description and comparison parameters, 
Elektrotehniški vestnik, 79(3), 2012. 
[3] Mobicents Presence Server,  
http://www.mobicents.org/index.html, (25.10.2012). 
[4] IMS Mercuro Client, http://www.mercuro.net , (5.7.2010). 
[5] Boghe, IMS/RCS client for Windows, 
http://code.google.com/p/boghe/ , (25.10.2012). 
[6] SIPp, http://sipp.sourceforge.net/, (25.10.2012). 
[7] Texting Top Teen Communication Link, April 20, 2010, 
http://www.marketingcharts.com/direct/texting-top-teen-
communication-link-12645/, (25.10.2012). 
 
Valerij Grašič obtained his B.Sc. and M.Sc. degrees from the 
Faculty of Electrical Engineering of Ljubljana (Slovenia) in 
1994 and 2002, respectively. Since 1994 he has been with 
Iskratel. His work includes research, development, design, and 
testing of traditional and IP telecommunications protocols, and 
research in the field of integration of modern heterogeneous 
networks. 
Andrej Kos is an associate professor at the Faculty of 
Electrical Engineering of Ljubljana (Slovenia). The focus of 
his scientific research is on telecommunications, multimedia 
and internet networks and systems on access, aggregation and 
backbone layer, testing, traffic analysis and optimization of 
resources, control protocols and development of converged 
multimedia services.