RiVS: Reputation in VoIP Systems

Bruno Freitas Cruz

and Bruno Sousa

Department of Informatics Engineering, University of Coimbra, Coimbra, Portugal

Keywords:

VoIP, SIP, IP PBX, Signalling, Reputation Systems, Internet Communications.

Abstract:

Voice-over-IP (VoIP) technology revolutionised telecommunications through inexpensive and ﬂexible com-

munications. Its growing user base worldwide across various sectors, including business, healthcare, and

telecommunications, originates from the rising demand for VoIP services, which exposes VoIP systems to

multiple threats. RiVS combines a reputation system based on the Alpha-Beta distribution to further enhance

the security of VoIP systems to protect against toll fraud, authentication attacks, and Spam over Internet Tele-

phony (SPIT). RiVS is integrated with the Asterisk server (known as IP PBX or VoIP server) operating as an

intermediary between the VoIP server and the reputation system. RiVS is able to parse user authentication or

call attempts to determined if they should be ﬂagged, dropped, or allowed through the system. The reputation

system keeps records of positive and negative actions. Experimental procedures were conducted to evaluate

system resources usage and response time. With results showing actions performed promptly with few system

resources, for consideration of cloud and on-premises deployments.

1 INTRODUCTION

Over the years, Voice-over-IP (VoIP) technology’s

rapid expansion, due to its cost-effectiveness and ﬂex-

ibility, has signiﬁcantly increased the associated se-

curity threats. The convenience and accessibility of

VoIP systems made them appealing targets for mali-

cious activities such as Spam over Internet Telephony

(SPIT), unauthorised access, and toll fraud. Posing

a ﬁnancial and privacy issue. Several reports (busi-

nessWire, 2023; Association, 2023; Insights, 2023;

Carter, 2023; gra, 2016) endorse these developments.

Reputation systems are capable of continuously

assessing the behaviour of network participants,

allowing real-time identiﬁcation and response to

threats, and are capable of incorporating dynamic and

adaptive security solutions. Allowing for more tar-

geted and efﬁcient security management and evaluate

users based on ongoing behaviour. RiVS analyses the

actions performed, the call source, and the duration of

the call, among other parameters that are used to es-

tablish the reputation score of the reputation system.

To evaluate RiVS performance, the Asterisk VoIP

server was chosen, as it is open source and widely

used as an IP PBX solution in enterprises. RiVS was

integrated with the Asterisk server and with the rep-

https://orcid.org/0009-0000-7873-7203

https://orcid.org/0000-0002-5907-5790

utation system to provide real-time monitoring, to re-

port activities and automatically handle activity based

on reputation scores of both Internet Protocol (IP) ad-

dresses and users. RiVS was evaluated in a Proof-of-

Concept (PoC) considering different types of threads

such as toll fraud, authentication attacks, and Spam

over Internet Telephony (SPIT). SPIT can be broad-

cast to any IP phone or server connected to the In-

ternet, and these calls continue to increase rapidly.

The idea is to create a genuine-looking message ca-

pable of deceiving protection mechanisms to gener-

ate spam calls or attempt to reach as many users as

possible to increase the chances of selling a product.

These calls can cause serious discomfort for the re-

cipients due to their intrusive nature. The Authenti-

cation attacks include attempts by bad actors to gain

unauthorised access by trying to register using default

manufacturer credentials or weak credentials. This is

commonly performed via brute-force or dictionary at-

tacks. The Toll Fraud refers to generating costs as-

sociated with using a hijacked user extension. An at-

tacker uses the IP PBX to make international calls or

calls to premium numbers, potentially using it to col-

lect revenue.

The remainder of this paper is organised as fol-

lows. Section 3 provides information on the reputa-

tion system. Section 4 describes the developed secu-

rity module, named VoIP WatchDog, which connects

Cruz, B. F. and Sousa, B.

RiVS: Reputation in VoIP Systems.

DOI: 10.5220/0013133300003899

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 11th International Conference on Information Systems Security and Privacy (ICISSP 2025) - Volume 2, pages 167-175

ISBN: 978-989-758-735-1; ISSN: 2184-4356

167

being the bridge between Asterisk and the Reputation

System. Section 5 details the use cases for testing the

security module. Section 6 concludes the paper.

2 RiVS: REPUTATION IN VoIP

SYSTEMS

2.1 Reputation System

The reputation system framework is composed of two

distinct components, the reputation system itself and

RabbitMQ. RabbitMQ is an open-source and asyn-

chronous message broker that processes messages be-

tween systems and applications, routing messages ac-

cording to deﬁned parameters. The reputation system

analyses the received data and calculates the score us-

ing the Alpha-Beta model. Reputation is calculated

by dividing the total number of positive events by the

sum of all positive and negative events, which means

that the result will vary between 0 and 1. However,

multipliers can change the range of these results. This

reputation model also contains an ageing factor that

is responsible for determining how much past actions

can inﬂuence new score calculations.

2.2 VoIP WatchDog - Security Module

The VoIP WatchDog Module is made up of six Python

scripts. The module is portrayed in Figure 1. Two

are related to Asterisk authentication, three to Call

Routing, and one to parse the Call Records/Reports.

The authentication scripts perform different actions.

The Call Routing scripts are fed by Asterisk with SIP

headers information. Call Tracker and Call Tracker

Cleaner complement each other, as without Cleaner,

the Tracker would not be viable in a test or production

environment. The Call Reports automatically fetch

data from Asterisk. This module bridges interactions

between Asterisk and the Reputation System, dynam-

ically blocks registration or call attempts, continu-

ously monitors for premium/international calls, and

tracks internal calls.

The main building blocks of the VoIP Watch-

Dog module include several components. The

CDR Parser automatically fetches and processes call

records when these are available in the Call Detail

Record (CDR) by going through the uniqueid, inter-

preting the database table. The Security.log Parser

will read and interpret the authentication logs of the

security.log ﬁle and send the information in JSON for-

mat to the Reputation System to determine the repu-

tation scores. The ACL Handler checks for IPs with

Figure 1: Security Module Framework.

a reputation score below ﬁve points in the database of

the Reputation System. It also conﬁgures the acl.conf

ﬁle to add IPs that meet the aforementioned crite-

ria but remove them if the reputation score exceeds

ﬁve. The Call Handler is fed with information and

activated by Asterisk through the Dial Plan, when

a SIP INVITE message arrives. It will log into the

Reputation System database and check the user score

database, so if one of the users has a score lower than

ﬁve, the call is terminated. The Call Tracker is acti-

vated and fed by Asterisk through the dial plan, after

the SIP Header information is extracted. This com-

ponent tracks calls from internal users using the ac-

tive calls database, which is automatically fed when a

SIP INVITE message arrives from the internal users,

being used to prevent a user on an ongoing call from

performing multiple calls. The Call Tracker Cleaner

is similar to Call Handler and Call Tracker, this com-

ponent is also fed and triggered by Asterisk A Dial

Plan, but after one of the sides terminates the call and

receives the SIP BYE message. It ensures that the ac-

tive calls database is cleaned when an explicit call is

terminated.

3 EVALUATION

METHODOLOGY

3.1 Methodology

The experimental scenario consisted in different vir-

tual machines with an Asterisk Server and a SIP

(Session Initiation Protocol) trunk, machines to run

soft phone software (MicroSIP, Zoiper and Jitsi), a

machine with the reputation system and the Rab-

ICISSP 2025 - 11th International Conference on Information Systems Security and Privacy

168

bitMQ instance, and a Kali machine for introducing

load or attacks in the remaining components. Three

experimental procedures were prepared to evaluate

the RiVS framework and system integration: Access

Control Lists, Flagging Users, and Call Monitoring.

3.2 Access Control Lists

Figure 2 represents the experimented scenario for

brute-force emulation, where the security module

identiﬁes malicious authentication attempts, ﬂags,

and blocks IPs. Two different IPs were used to test the

current scenario of the reputation-based access con-

trol list (ACL) conﬁguration. The ﬁrst Internet Proto-

col (IP), 10.0.0.5, has a score of 2,90 in the IP score

database, while 172.0.0.4, belonging to the Kali ma-

chine, has a score of 6. The ﬁrst IP is an entry from

preparatory tests, and as a result, it is already present

in the acl.conf ﬁle with a low score.

Using the Kali machine, a word list with random

passwords was used to emulate user enumeration,

where eight attempts were generated. The moment

VoIP WatchDog detects new entries in security.log, it

parses them and sends the appropriate information in

JSON to RabbitMQ, which will queue and route the

information to the Reputation System to calculate the

reputation score and allow it to be stored; so many at-

tempts caused the score to go lower than ﬁve (5). Af-

ter updating the newly calculated reputation score in

the Reputation System database and communicating

the updated score via RabbitMQ, the module updates

the acl.conf ﬁle. It reloads the Asterisk ACL mod-

ule as a new IP with a score less than ﬁve (5) can be

found. From here on, any authentication from these

IPs is no longer allowed.

Figure 2: Access Control List Trial.

3.3 Flagging Users/Extensions

Figures 3 presents a scenario of identifying users

through Call Detail Records (CDR) for the identiﬁ-

cation of spam. Extension 221 initiates the extension

call from behind Asterisk B. Asterisk A receives the

call request on the trunk and forwards it to extension

103. At this point, Asterisk already knows that the

call is externally sourced. The call lasted more than

thirty seconds, so after the call was ﬁnished, the CDR

was immediately ﬁlled with the records of that com-

munication. The VoIP WatchDog immediately parses

the new entry in the CDR. The user is ﬂagged as posi-

tive, and the module sends a message to RabbitMQ in

JSON format. This queues and sends data to the repu-

tation system for reputation score calculation. A new

entry is created in the Reputation System database

with user scores if the user does not have a previous

record. As the ﬁrst ﬂag for extension 221 is positive,

it is assigned a reputation score of 6.

Figure 3: Flagging Users Positively.

Otherwise, if it were a negative ﬂag for the ﬁrst

time, the assigned reputation score would be 4. It

should be noted that the reputation score is initiated

with the value ﬁve (5) by default, which means that

there is not enough information to determine whether

an entity is trustworthy or not.

3.4 Call Monitoring

VoIP WatchDog always monitors the user score and

active calls. For the ﬁrst scenario, the same user was

logged in to two different softphone applications. The

ﬁrst call reached extension 221, ﬁlling the active call

database with the ongoing call information. When the

second call was initiated from the other application, it

was terminated, thanks to the existing entry for track-

ing calls; otherwise, it would have gone through. En-

tries are cleared by Asterisk right after the call has

been terminated, leading to the interception of multi-

ple calls from the same source.

Secondly, the call is automatically terminated if

any user in a call attempt has a score lower than ﬁve

(5). Scenario II considers that if both the source and

destination have a score equal to or higher than ﬁve

(5), the calls proceed (From: 102, To: 221); other-

wise, they are rejected (From: 598, To:102). This ap-

plies in both directions.

Third, it tracks whether a bad actor is maliciously

trying to establish calls from a network other than the

Asterisk A local network (192.168.1.0/24). This call

RiVS: Reputation in VoIP Systems

169

is prevented and the source IP signalled with a nega-

tive ﬂag. Otherwise, without this procedure, the call

will be registered as sourced from Asterisk A, result-

ing in costly fees. So, even if the trunk credentials get

exposed for unknown reasons, or there is an unknown

exploit that would allow generating a call externally,

this provides an additional security layer. Allows re-

jection and ﬂagging of calls from unknown IPs that

could self-identify as internal users, as shown by Fig-

ure 4.

Figure 4: Call monitor - Scenario III.

4 EVALUATION RESULTS

4.1 Access Control Lists

The time achieved for Step 1 - Parse security logs and

Step 2 - Send information to RabbitMQ is between

0.001 and 0.005 milliseconds (ms) to parse each row

individually. The time discrepancy is related to the

amount of content parsed when searching for the rel-

evant conditions.

The results achieved for Step 4 - Send information

to the reputation system, Step 5 - Calculate the reputa-

tion score, and Step 6 - Propagate the reputation score

took on average 2 ms to complete the message request

for the RabbitMQ score calculation and send it back

to update the IP score database.

Step 7, which refers to updating the score database

in RabbitMQ docker, is not available. However, fol-

lowing previous observations and tests, it should not

take more than a few milliseconds. This characteristic

is shared by all scenarios. Figure 5 refers to steps 8

and 9 of ﬁgure 2.

• In red are the IPs fetched from the IP score

database in RabbitMQ docker. Connecting to the

database and fetching all IPs and respective scores

took 6.397 ms. In another attempt, the same ac-

tion took only 2.805 ms.

• In orange is how long the module took to conﬁg-

ure the acl.conf ﬁle with the newly founded IP,

taking only 0.159 ms.

• In yellow is the time to reload the Asterisk ACL

module after reconﬁguring the ACL ﬁle, taking

only 5,812 ms. It takes 5,971 ms to conﬁgure

acl.conf and reload the Asterisk ACL module for

the new conﬁguration to take effect.

• In blue is the CPU utilisation. The CPU usage

was always recorded as less than 1% remaining

at 0. 00% the whole time. With cycle process-

ing time representing the entire cycle time, from

data extraction from the database to conﬁguring

acl.conf and reloading the Asterisk ACL module

for the conﬁguration to take effect.

• In green is the RAM usage. Under normal oper-

ations, the ACL component only uses 23.43 Mb

and, at most, would make use of 31.79 Mb.

Disk read / write is at 0.00 Mb; however, writing

is at 0.01 Mb, which should correspond to editing the

acl.conf ﬁle. The network utilisation is shown at 0.00

Mb.

Figure 5: ACL benchmarking.

Ten samples were retrieved to calculate how

quickly IPs are blocked from initial detection to score

calculation and acl.conf ﬁle conﬁguration. Further-

more, it always considers updating the ﬁle with any

IPs that should be added, removed, or kept, depend-

ing on the database scores.

Figure 6: ACL response times.

ICISSP 2025 - 11th International Conference on Information Systems Security and Privacy

170

According to ﬁgure 6, it took an average of 6.116

ms, with a variation of 0.0264 ms. The longest time

was 6.381 ms and the lowest was 5.5852 ms. Such

values indicate an acceptable performance for ACL

functionalities in the RiVS framework.

4.2 Flagging Users/Extensions

This section documents the performance and utilisa-

tion of the resources of the ﬁgures 3 Steps 1 and 2.

The CPU utilisation varies. The processing of

1605 lines took 260 ms with a CPU utilisation of

40.45%. This includes the parsing and sending in

JSON format to RabbitMQ. The processing of a new

line, leads to CPU utilisation at 0.00%. The RAM

utilisation, under normal operations, the ACL com-

ponent only utilises 27.57 Mb and, at most, would

make use of 107.64 Mb. The Disk I/O read is at

0.00 Mb, however, writing is at 0.36 Mb, this value

should correspond to the module logging the parsing

and sending of each line of the CDR database. And

network utilisation is shown with a value of 1.17 Mb

after sending 1605 JSON messages.

The operation of fetching a new CDR record has

the following resource utilisation. The RAM utilisa-

tion increased by 0.02 Mb, but since it is the same

module and running continuously, it could be related

to a momentary memory speak. The Disk I/O write

operation increases to 0.37 Mb. This is because the

module logging will print data related to fetching the

CDR every 5 seconds.

The performance of performing Step 1 - Parsing

call records depicted in Figure 3 relies on the step 1

average and deviation response times for parsing 1716

rows in the Call Detail Record (CDR) database. An

average response time of 270 ms was achieved, which

translates to 0.1573 ms to process each row. The

samples always matched the same processing time,

without deviation, that is, the standard variation is

0.000000 ms.

The steps Step 4 - Send information to reputation

system, Step 5 - Determine reputation score, Step 6

- Communicate reputation score the achieved values

to determine the reputation score rely on the order of

2 ms, which is inline with the value achieved in the

access control list scenario.

Figure 7 presents the average and deviation re-

sponse times for the reputation system score calcu-

lations, which lead to an average of 2.1 ms. The hor-

izontal red line indicates an average response time of

2.1 ms. For most requests, the response times reside

close to the average line, indicating consistency. The

standard variation is 0.567646 ms. Even if most sam-

ples reside close to the average processing time, there

are a few outliers. This could be related to a few

events that occasionally impact response times within

the system.

Figure 7: Reputation System score calculation response

times.

The performance values achieved were in line

with the results of the access control list scenario.

This shows stability in the RiVS framework in assess-

ing the reputation score for VoIP information.

4.3 Call Monitoring

The utilisation of resources of scenario I with re-

spect to active call tracking includes the time to query

data from the database, the CPU and RAM utilisa-

tion rates. Connecting to the active call database took

3.209 ms. And querying for any active call source

from extension 103 took only 0.0384 ms. The time it

took to ﬁll the database with the ongoing call is 1.335

ms. However, it can be obtained by subtracting the

database query and the database connection time from

the overall processing time. The measured CPU rate

is on the order of 0. 00%, while the RAM usage under

normal operations, the call tracking component only

uses 26.60 Mb and, at most, would use 106.84 Mb.

Figure 8 provides the performance and use of re-

sources of Scenario II. The utilisation of resources of

scenario II includes the same metrics as in scenario I.

The connection to the database takes only 0.059 mil-

liseconds. The time to fetch the extension score is

0.83 milliseconds. The hangup action includes log-

ging into AMI (Asterisk Management Interface) and

executing the hangup command, taking only 0.181

ms. The CPU utilisation is 0.00% and the RAM util-

isation under normal operations, the hangup compo-

nent only utilises 23.49 Mb and, at most, would use

31.86 Mb.

Figure 9 provides the results of the use of re-

sources in scenario III provides the performance and

use of the resources in Figure 4. The connection to

the database to check active calls took 3.248 ms, and

querying for active calls took 0.305 ms. The detec-

tion of incoming call IP trying to reach extension 221

and block the malicious attempt and sending a JSON

RiVS: Reputation in VoIP Systems

171

Figure 8: Hangup Scenario II benchmarking.

Figure 9: Hangup Scenario III benchmarking.

message took 10.4 ms, which correlates with a TLS

connection. The CPU usage is 0. 00%, while us-

ing RAM under normal operations, this part of the

hangup component only uses 26.71 Mb and, at most,

would use 178.84 Mb. The network data display both

0.01 Mb, which can be correlated to receiving calls

and sending the call termination packets.

Figure 10: Call Monitor response times.

Figure 10 presents the average and deviation re-

sponse times for the Call Routing component of VoIP

WatchDog. The blue dots represent the sample num-

ber. The X-axis is the sample number and the Y-axis

is the response time in ms. The horizontal red line

represents the average. The horizontal red line indi-

cates an average response time of 2.932 ms. Most of

the time, response times reside close to the average

line, indicating consistency. The standard variation is

1.423231 ms. Response times spread across a rela-

tively signiﬁcant area, suggesting considerable varia-

tion. Most response times reside within the variation

area, especially in the lower parts, and some are close

to the average.

The average response time is higher in this sce-

nario, as it includes the processing from the Watch-

Dog component in the RiVS framework, compared to

the previous scenarios. Notwithstanding, the achieved

results (i.e., 2.932ms) are still acceptable for VoIP

communications.

4.4 RabbitMQ Messaging

In order to test RabbitMQ capabilities, the CDR sent

3242 lines of information in individual JSON mes-

sages. At its peak, RabbitMQ successfully processed

more than 800 messages per second without dropping

any of them, as shown in Figure 11. RabbitMQ took

20 seconds to process all 6484 messages. This means

that processing of each message takes 3.083 ms in av-

erage.

Figure 11: RabbitMQ - Messages processing rate.

The choice of RabbitMQ demonstrates that it is

possible to have a reliable communication channel be-

tween the components of the RiVS framework.

4.5 Docker Container’s

The resource utilisation ﬁgures presented here were

taken during the previous section scenario exercise

of processing 3242 data lines from the CDR. Consid-

ering message processing capabilities, the number of

lines took around four (4) seconds to receive and pro-

cess through the Reputation System. Any additional

processing time is related to post-JSON data. In the

upcoming ﬁgures, a dot represents the start, and a line

at the end of the 3242 lines that were processed. Past

that point, it is related to post-JSON actions, which

involve reputation update routing policies. In the ﬁg-

ures, red is the CPU utilisation, followed by the RAM

in orange and network utilisation in green.

Reaching a spike of 0.4 in the Cores axis of Rab-

bitMQ indicates that 20% of the processing power

was utilised during an average time frame of around

4 seconds (Asterisk A is running with 2 cores). With

ﬁgure 13 running stable slightly above 0, on standby,

and innately increasing when data needs to be pro-

cessed.

RabbitMQ in ﬁgure 15 and the Reputation System

in ﬁgure 16 showed RAM (Random Access Memory)

efﬁciency. But the same cannot be said about MySQL

database in ﬁgure 17.

ICISSP 2025 - 11th International Conference on Information Systems Security and Privacy

172

Figure 12: RabbitMQ CPU.

Figure 13: Reputation System CPU.

Figure 14: MySQL CPU.

When queuing and processing over 3242 JSON

packets, RabbitMQ used 175 megabytes (Mb) of

memory, spiking slightly above 200 megabytes when

routing trafﬁc for the Reputation System and between

score updates in between the MySQL database and

the Reputation System.

In these Memory ﬁgures, Total represents all

the memory allocated to the container, regardless of

whether it is utilised. At the same time, Hot refers to

the amount of memory actively used.

After initialisation, the Reputation System was ac-

tively using 60 Mb of RAM, from a maximum of 100

Mb if required. After processing the 3242 packets, it

started actively using 125 Mb and around 170 Mb and

remained stable throughout further experiments.

The MySQL database in ﬁgure 17 was using

slightly more than 475 Mb and was increasing close to

487,5 Mb but capable of reaching more than 500 Mb

in use. The reason for so much RAM is related to not

only containing asterisk records but also information

for RabbitMQ and the Reputation System.

Figure 15: RabbitMQ Memory.

The network utilisation is very low and will not

easily cause network congestion. In Figure 18,

3242 JavaScript Object Notation (JSON) messages

Figure 16: Reputation System Memory.

Figure 17: MySQL Memory.

generated incoming network trafﬁc of up to 0.45

Megabyte(Mb)/s = 450 000 Bytes per second.

Subsequently, received (Rx) bytes are related to

reputation update exchanges, with the same type of

trafﬁc applied to transferred (Tx) bytes, including the

3-way handshakes. Reputation exchanges are sepa-

rated into two parts: First comes the score calculation

and then updating the score.

Figure 18: RabbitMQ Network usage.

In ﬁgure 19, Tx reputation score was 0.25 Mb/s.

However, the Rx information from the last updated

scores led to a slight increase above 0.3 Mb/s. In ﬁg-

ure 20 a Tx rate of 0.05 Mb/s and Rx rate of 0.01 Mb/s

peak around 0.15 Mb/s.

Figure 19: Reputation System Network usage.

Figure 20: MySQL Network usage.

After sending the calculated reputation update,

RabbitMQ will provide the Reputation System with

RiVS: Reputation in VoIP Systems

173

the latest calculation. When a packet arrives in the

Reputation System, it opens it, performs the calcu-

lations, and replies to RabbitMQ. Hence, RabbitMQ

job is to queue these reputationUpdate messages and

forward them to the MySQL and Reputation System.

So, the remaining bulk of the network trafﬁc past

the green line is the trafﬁc associated with what is ob-

served in ﬁgure 21 and is applied to ﬁgures 19 and 20.

Figure 21 shows an example of a calculated score for

extension 200 but then came in another JSON with a

positive ﬂag to increase the extension score. Hence,

the Reputation System does its job by again calcu-

lating the score and releasing a new update for which

RabbitMQ will route the reputationScore messages to

inform the database for VoIP WatchDog access and

the Reputation System.

Figure 21: Reputation Update from RabbitMQ.

5 CONCLUSION AND FUTURE

WORK

Voice-over-IP (VoIP) will continue to rise due to the

need to have continuous and inexpensive communi-

cation methods. However, this continuously brings

about various security challenges, such as Spam over

Internet Telephony (SPIT), toll fraud, and brute-force

attacks, endangering the integrity and dependability

of VoIP networks. In response to these threats, the

RiVS framework explored the implementation of rep-

utation systems as a proactive security measure, offer-

ing a way to improve the resilience of VoIP systems

against malicious actors.

Although the CDR parser component effectively

addresses the identiﬁcation of SPIT according to the

deﬁned set of parameters, the integration of Machine

Learning (ML) would present a substantial reﬁne-

ment. The parameters involved deﬁning a value on the

call’s duration to determine whether a call was spam.

During the evaluation, the performance results

show that actions are performed quickly and the sys-

tem remains stable. For example, on average, to

process an individual event, RabbitMQ takes 3.083

milliseconds (ms) to process each message, Repu-

tation System 2.1ms for score update, CDR Parser

0.1573ms for processing a row, Call Routing Module

2.932ms to handle calls, and Authentication Module

6.1744ms to conﬁgure and restart the Access Control

List (ACL) for immediate effect. Some variations can

be observed, but are not unreasonable according to the

output. Demonstrating efﬁciency and stability, which

can contribute to future enhancements.

However, VoIP WatchDog was built using Python

scripts, meaning that a new shell process runs every

time it is executed, consuming resources every time,

even if by a small amount. Due to limitations, perfor-

mance bottlenecks are not noticeable in such an ex-

perimental PoCs, and the volume of calls is low com-

pared to the volume generated in a production envi-

ronment, where they could have serious bottlenecks.

As future work, we consider the following: 1)

Enhance spam detection through the implementation

of ML.2) Implement an Asterisk Gateway Interface

(AGI), to take advantage of FastAGI, to improve all

operations involving database connections, log pars-

ing, call control and reduce resource consumption fur-

ther and the load on the Asterisk Server, since the se-

curity module requires to be installed on the Server.

3) Deploy the Reputation System in the cloud, to em-

ulate a public facing service.

ACKNOWLEDGEMENTS

This work implemented a reputation system that

was developed through the ARCADIAN-IoT project,

sponsored by the European Union’s Horizon 2020 re-

search and innovation programme and supported un-

der grant agreement number 101020259. This work

has been supported by Project “Agenda Mobilizadora

Sines Nexus”. ref. No. 7113), supported by the Re-

covery and Resilience Plan (PRR) and by the Euro-

pean Funds Next Generation EU, following Notice

No. 02/C05-i01/2022, Component 5 - Capitalisation

and Business Innovation - Mobilising Agendas for

Business Innovation. This work is also funded by Na-

tional funds through the FCT- Foundation for Science

and Technology, I.P., within the scope of the project

CISUC-UID/CEC/00326/2020 and by the European

Social Fund, through the Regional Operational Pro-

gram Centro 2020.

REFERENCES

(2016). Mobile voip market size to reach $145.76 bil-

lion by 2024. https://www.grandviewresearch.com/

press-release/global-mobile-voip-market. Accessed:

2023-11-06.

Association, C. F. C. (2023). Telecommunications fraud

increased 12% in 2023 equating to an estimated 38.95

billion lost to fraud. https://bit.ly/4byIiLF. Accessed:

2024-01-03.

businessWire (2023). Hiya report: A quarter of all unknown

calls in the world are spam and fraud. https://www.

ICISSP 2025 - 11th International Conference on Information Systems Security and Privacy

174

tmcnet.com/usubmit/2023/05/02/9805850.htm. Ac-

cessed: 2024-01-02.

Carter, R. (2023). The ultimate list of voip statistics (2024).

https://ﬁndstack.com/resources/voip-statistics/. Ac-

cessed: 2023-11-06.

Insights, G. M. (2023). Voice over internet protocol (voip)

market. https://bit.ly/3xNZAXp. Accessed: 2023-11-

03.

RiVS: Reputation in VoIP Systems

175