Proceeding of the 3rd International Conference on Informatics and Technology, 2009

USING CAPTCHAs TO MITIGATE THE

VoIP SPAM PROBLEM
,VPDLO$KPHG\0DULXV3RUWPDQQ

ABSTRACT

Voice over Internet Protocol (VoIP) is one of the emerging technologies today. This application offers the user a
service by which one can call another person at a low cost as compare with traditional phone services. One
drawback to the Internet is spam, which are unsolicited or unwanted objects which often appear as unwanted
messages in various email applications. For VoIP, spam refers to unsolicited and unwanted calls by the VoIP user. In
this paper, we have purposed a solution to prevent the spam in VoIP. The CAPTCHA (Completely Automated Public
Turing Test to Tell Computers and Human Apart) method aims to determine whether the call is coming from a human
or a machine. The key contribution of this paper is a proof-of-concept implementation of a CAPTCHA mechanism to
prevent VoIP Spam.

Keywords: CAPTCHA, VoIP, SPAM, VoIP user, integrate, VoIP client software

1.0 INTRODUCTION

Voice over Internet Protocol (VoIP) is a technology which uses packet switched networks to transmit real voices via
the Internet. This technology also can be referred as IP telephony, Voice over broadband or Internet Telephony. The
traditional telephony service which is PSTN (Public Switched Telephone Network) is circuit-switched, but VoIP uses
packet networks since it uses Internet Protocol (IP) to transmit the voice packet. The VoIP application uses the
Session Initiation Protocol (SIP) to establish calls between two VoIP users. Spam or unsolicited messages is one of
the major problems for e-mail services. Since e-mail uses the Internet as a medium for communication, the problem
of spam can be a major problem for VoIP as well since it is provides a similar service to e-mail.

1.1 Background Problem

VoIP offers a low cost beneficial on telephony services [1]. This advantage attracts the spammer to send spam
message using VoIP application since it offers a cheaper services rather than tradition telephony services. As far as
we are concerned, the spam message in VoIP can be annoying the VoIP user since the message is playing
automatically by itself. There are different types of VoIP spam [2]:

i. Call Spam: Number of calls to attempt user VoIP. If user answers the call, the user hears a recorded
message and the call ends when the message finishes. This type is used by spammers on PSTN for
marketing and is used widely by telemarketers as well. This type of spam is also known as Spam over
Internet Telephony (SPIT).
ii. IM Spam: This type, which is similar to email spam, describes the bulk of unsolicited messages where the
spammer uses Instant Messaging (IM) to send spam to the VoIP user. This type of spam is also known as
Spam over Instant Messaging (SPIM)
iii. Presence Spam: This is similar to IM Spam since it consists of a large number of unsolicited set of
presence requests. It means that the message is trying to get authenticated or ‘white listed’ by the VoIP
user. This is also known as Spam over Presence Protocol (SPPP).

In this paper, we are focusing on the call spam or SPIT problem in VoIP applications. As we know, most of spam in
VoIP is in the form of automatic voice play which is a SPIT. SPIT is sending to the large number of user and when
user accepts the call from the machine that sends the SPIT, the voice message is automatically play. The scenario is
quite different with the email spam since the VoIP application is synchronous communication and email application
is asynchronous. VoIP is synchronous since the communication initiates at the same time when the sender wants
to communicate with the receiver. The receiver and sender must be connected at the same time. In contrast, email is
asynchronous since the receiver does not have to be connected with the sender to establish communication. When
the sender sends a message, the message is stored on a specific server and is unveiled by the receiver at a time of
his choosing. Hence, this communication is asynchronous since the receiver does not connect with the sender at the
same time.

Next section will describe on the Session Initiation Protocol (SIP) environment. Later on, the framework of the
proposed method will be shown.

1.2 Session Initiation Protocol

SIP is one of the protocols for the VoIP application which has been standardized by the Internet Engineering Task
Force (IETF) [3]. It is used for the signalling process in the telephony application to initiate, establish and terminate

©Informatics '09, UM 2009 RDT6 - 235

 Proceeding of the 3rd International Conference on Informatics and Technology, 2009

calls. There are two general components for SIP in the VoIP application environment: User Agent (UA) and SIP
proxy. UA acts as a VoIP client while UA can be referred to as a client in SIP architecture. The call establishment
starts on the UA side before it through to the other user. The SIP proxy is responsible to establish calls when a call
request has been made by the UA. According to [3], there are four logical components which make up the basic SIP
architecture: UAs, registrars, proxy and redirect servers. UA acts as a client basis where it is responsible to initiate
the SIP request to another UA which is also a client. The registrars are responsible to manage all the UAs in the
same domain so it knows the SIP domain to which each client belongs. The proxy server acts as a router to forward
the SIP request from UA to the UA destination. Redirect servers are responsible to redirect the SIP request to
another SIP network where the destination UA might be.

2.0 RELATED WORKS

There are number of method which has been implemented to prevent the VoIP spam problem. In method [8], the
author uses a decoying system to block the SPIT senders. To block these unwanted calls, the author suggests a
decoy be used to detect legitimate calls to the user. The decoy should be a non-existing user in the same proxy. This
decoy should have an address and the address should be posted on the Internet where the address can be detected
as a decoy by humans but not by machines. When the caller attempts to send to the decoys address two or more
times, the user is automatically blocked. When the decoy receives or is hit by spammers, it automatically stores the
information regarding the spammers and informs all other users about this sender’s information. The users can put
the sender information received from the decoys into their black lists account. Unfortunately, this technique is not
foolproof as it is dependent on the decoy’s address. If the spammer learns that a decoy has been set up, the
spammer can change his information each time he sends spam.

Signal analysis method has been suggested by [9] where it uses a signal in the voice message to detect all SPIT
messages coming through the Gateway or SIP. The problem addressed here is that the caller recipient does not
know the caller’s identity and, of course, the caller could be a spammer. The author shows three ways to detect a
pattern from spammers. One of the detection methods used to identify the majority of spammers sending SPIT over
the network employs a unidirectional process [9]. The spammers use the FROM: header field which targets the VoIP
network proxy. As usual, all users are registered in the SIP proxy. From the SIP proxy, the message can be spread
inside the proxy or to another proxy. This technique is not applicable to the VoIP spam problem since the specific
technique involves observation of the SPIT attack pattern. It also requires the VoIP user to observe all calls from any
caller, which makes the technique quite inefficient and inconvenient for the user.

In research paper [10], the author used a ‘grey’ level as a threshold to determine whether the caller is a spammer or
not. The term ‘grey’ indicates its position on a level between the white and black lists [10]. The white and black lists
are commonly used in the email system to prevent spam in email applications. All calls are analysed by the PMG
algorithm to determine whether they are VoIP spam or not. The result has a grey level value to be determined at a
certain threshold. If the grey level value is higher than the threshold value, the call is identified as spam and blocked.
The grey level of the caller is not permanent which means that it can change anytime regardless of the analysis of the
calls. The black list approach dictates that the caller is permanently blocked as the caller is unable to remove himself
from the user black lists. PMG analyses call patterns when a user intends to establish calls. The grey level of the
caller is determined by analysing the way users make the calls over time [10]. The user’s calls are blocked when the
grey level reaches the limits of the given threshold. As previously mentioned, the PMG method is not permanent like
the black list approach, as the caller stops sending spam within a certain time [10]. This scenario makes the grey
level decrease and the caller is permitted to make calls again.

3.0 CAPTCHA METHOD

CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Human Apart) uses the Turing Test
approach to determine whether the user or caller is human or machine [4]. Email is one application that uses the
CAPTCHA method to prevent spam entering the user’s mailbox. The strength of this method and its success in
preventing spam in email made it appealing as a means of preventing spam in VoIP applications. Figure 1 shows an
example of CAPTCHA image.

Fig. 1: Example of CAPTCHA image

©Informatics '09, UM 2009 RDT6 - 236

 Proceeding of the 3rd International Conference on Informatics and Technology, 2009

The basic idea of this method is to implement a challenge-response application for call establishment in VoIP
application. As shown on figure 2, Alice is trying to establish a call with Bob and Bob challenge Alice with CAPTCHA
images to prove Alice is a human rather than a machine. Alice needs to response with the correct answer of the
CAPTCHA in order to establish calls with Bob.

The main purpose of using the challenge-response is to prevent the spammer from establishing call with the VoIP
users. In order to implement this approach, the CAPTCHA application needs to be integrates with the existing UA
clients. The CAPTCHA application has been implemented as a pop-up application in the existing UA client.

In the next section, the implementation on this method will be described.

Fig. 2: Challenge-Response Scenario for CAPTCHA Method

4.0 IMPLEMENTATION

Basically, the UA functionality is to establish a call between the UA and another UA. All the processes for establishing
a call, initiating a call, and sending the SIP message request and response are done in the UA client software. The
approach solution using a single independent window program to shows a CAPTCHA image and to receive an
input which is the answer from the user. The window program has been implemented as a pop-up window
application in the UA client where the pop-up window only executes when the UA intends to initiate a call with
another UA. The pop-up window is not executed if the UA receives a call from the other UA. The preliminary research
on this approach is to find a suitable way to fit the pop-up window program into the existing UA client to ensure all the
processes mentioned above execute correctly.

While most CAPTCHA applications are used in an Internet based environments, the proposed solution has been
implemented in the UA client applications. This application has used only one CAPTCHA image which is shown in
the CAPTCHA window application. This image is identified by a URL (Uniform Resource Locator). For example, the
URL for the CAPTCHA image is “http://10.1.1.2/try/images/captcha1.jpg” where this URL points to the location of the
CAPTCHA image.

In order to send the URL to the CAPTCHA pop-up window application, the TCP connection has been used for this
purpose. The TCP port is open when the user starts the call establishment process. When the user starts the call, the
recipient is acknowledge it with the URL message of the CAPTCHA. Once the user has answered the CAPTCHA
correctly, the call is established.

As mentioned before, the integration of the CAPTCHA method with the existing UA client needs to be done. First of
all, the selection of suitable UA client has been made for this purpose.

4.1 MjUA SIP UA

Most VoIP applications are open source at the present time. As mentioned before, the approach for spam solution in
VoIP is to be used in the VoIP client application software. One of the open source has been selected to implement
this research to see whether this approach is suitable on each open source VoIP client. For this research, we have
selected MjUA [11] from MjSIP application as a VoIP client for implementing the approach and integrate it.

The main outcome of this project research is: the program is able to block spam calls without user interference. The
program automatically blocks any attempted call that is suspected to be spam with a challenge program embedded in
the VoIP client. Each call that attempts the VoIP client is not permitted to establish or request a call unless the sender
provides the correct CAPTCHA answer when challenged.

Figure 3 shows the connection to Alice finally established after Bob answer the CAPTCHA correctly. In contrast to
Figure 3, Figure 4 shows the VoIP client is blocked from establishing a call with Alice because the answer to the
CAPTCHA is not correct. A pop-up window has appeared to alert the user that the call is not authorized.

©Informatics '09, UM 2009 RDT6 - 237

 Proceeding of the 3rd International Conference on Informatics and Technology, 2009

Bob enters the

correct answer

Fig. 3: MjUA client establishes call after correctly answering the CAPTCHA

Fig. 4: MjUA client is not permitted for established calls

The approach method employed in this VoIP client has proved that it can block any unsolicited calls without
interrupting the user. The program is able to prevent spam while hiding the process from the user itself. The pop-up
window application makes it more interactive for the user who intended to call somebody. The method approach
guarantees the calls can only be made by legitimate users since the pop-up application is embedded into the VoIP
client and only a user permitted to use the VoIP client can make a call. This proves that a machine cannot send spam
to the VoIP client who used the program as it will challenge any incoming request who intends to establish a call. The
used of URL approach for showing the CAPTCHA has shown that it can manage the image perfectly. The CAPTCHA
image itself does not need to be sent through the network since the image size can slow the whole process. Instead
of sending the CAPTCHA image through the network, only a URL is sent; this approach is faster and more efficient.

5.0 DISCUSSION AND FUTURE WORK

The SPAM prevention method has proved that it can block any unsolicited calls without interrupt the user. The
program itself has the ability to do the prevention with hiding the process from the user itself. The pop-up window
application makes it more interactively to the user who intended to calls somebody. The solution also can guarantee
the calls can be made from the legitimate user since the pop-up application is embedded into the UA client and only
the user who permitted to use the UA client can makes a call. This proof that a machine can’t send a SPAM to the UA
client who used the program since it will challenge any incoming request who intended to establish a call. This
solution is mainly focus to block or denied any SPAM in VoIP and has been implemented without changing any
structure in the SIP protocol program in the MjUA client application. As mentioned before, SIP protocol is used to
establish a connection between two users in VoIP application. The solution ability was to challenge any intended calls
makes from any users before the SIP establishment can be executed.

The CAPTCHA URL approach has shown that it can manage the image in perfect way. The CAPTCHA image it self
doesn’t need to being send through the network since it can slow the whole process because the image size it self.
The only thing that has been done is a URL is being sent through the network instead of the CAPTCHA image. This

©Informatics '09, UM 2009 RDT6 - 238

 Proceeding of the 3rd International Conference on Informatics and Technology, 2009

approach can utilize the whole timing process and a lot faster if sends the image through the network. The pop-up
application just needs to use the URL for showing the CAPTCHA image. The pop-up application has been enabled in
the program to showing the image using an URL. The user doesn’t have to wait for the image to be appearing since it
doesn’t take a long time for the URL to locate the image. The only problem in this approach is only one CAPTCHA
image is being used for CAPTCHA challenge. To overcome this problem, the CAPTCHA handler should select
randomly CAPTCHA image from the CAPTCHA location.

The answer that has been received is being checked within the CAPTCHA program. The approach doesn’t seem well
because it checked in the program itself. If the user can extract the program, all the answer can be seen and the
attacker can used all the answer to be programmed for guessing every CAPTCHA image. Even though the extraction
of program seems to be impossible, but the attacker can learn the answer in many ways since that’s the attribute of
the attacker. This weakness seems the only flaws in the solution implementation.

In the CAPTCHA URL sending process, the only thing that has a drawback is that the particular process is not
entirely in the SIP protocol itself. As mentioned before, the sending process used TCP connection to sends the
CAPTCHA URL before the call establishment process can be executed. This should have a problem when two
different UA clients want to communicate to each other since the implementation on each UA has a different way of
doing it. Call establishment in SIP is a standard in the VoIP application. If the SIP call establishment process can be
restructured to implementing the CAPTCHA challenge method, it should not be a problem if two different UA clients
want to communicate since every UA clients need to follow the standard for call establishment in SIP. The restructure
process need a quite of time since the protocol for the call establishment has been implemented using the SIP
standard. To restructure it, the SIP call establishment need to be reorganized with some challenge procedure since
the CAPTCHA method needs to be implemented in the call establishment process.

The proposed solution outcome also has made the user more comfortably since the challenge didn’t involve the user
entirely. The user only knew there is a call request when the CAPTCHA challenge has been finished. The call
initiation process can’t be executed unless the CAPTCHA challenge is successfully done. The program that has been
embedded has been shown that it will deny any call initiation process until the challenge is done.

5.0 CONCLUSION

The key contribution of this paper is a proof-of-concept implementation of a CAPTCHA mechanism to prevent VoIP
spam. The spam prevention in VoIP that has been implemented on this project provides an advantage especially
from the user’s point of view. We have demonstrated that the CAPTCHA method can be applied in the VoIP
applications. The method also has been adapted to fit in with the selected VoIP client during the execution of the
entire process. As mentioned before, there are some limitations in our implementations. The purposed solution that
we’ve come out has shown the successful for preventing spam in VoIP. This solution can be expend to integrate with
the SIP protocol to make the solution approach been acceptable by all the VoIP client application since the SIP
protocol is a standard for the VoIP application.

REFERENCES

[1] So Young Park; Jeong Tae Kim; Shin Gak Kang, "Analysis of applicability of traditional spam regulations to
VoIP spam," Advanced Communication Technology, 2006. ICACT 2006. The 8th International Conference,
vol.2, no., pp. 3 pp.-, 20-22 Feb. 2006.

[2] Rosenberg, J., Jennings, C., “The Session Initiation Protocol (SIP) and Spam,” RFC 5039, January 2008.

[3] Schulzrinne, H.; Rosenberg, J., "The Session Initiation Protocol: Internet-centric signalling,"
Communications Magazine, IEEE , vol.38, no.10, pp.134-141, Oct 2000.

[4] Luis von Ahn, Manuel Blum and John Langford, “How Lazy Cryptographers do AI In Communications of the
ACM,” Feb. 2004.

[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, “SIP: Session Initiation Protocol,” RFC 3261, June 2002.

[6] Shirali-Shahreza, S.; Movaghar, A., "A New Anti-Spam Protocol Using CAPTCHA," Networking, Sensing
and Control, 2007 IEEE International Conference on, vol., no., pp.234-238, 15-17 April 2007.

[7] Hoanca, B., "How good are our weapons in the spam wars?," Technology and Society Magazine, IEEE ,
vol.25, no.1, pp. 22-30, Spring 2006.

©Informatics '09, UM 2009 RDT6 - 239

 Proceeding of the 3rd International Conference on Informatics and Technology, 2009

[8] Salehin, S.M.A.; Ventura, N., "Blocking Unsolicited Voice Calls Using Decoys for the IMS," Communications,
2007. ICC '07. IEEE International Conference on, vol., no., pp.1961-1966, 24-28 June 2007.

[9] MacIntosh, R.; Vinokurov, D., "Detection and mitigation of spam in IP telephony networks using signalling
protocol analysis," Advances in Wired and Wireless Communication, 2005 IEEE/Sarnoff Symposium on ,
vol., no., pp.49-52, 18-19 April 2005.

[10] Dongwook Shin; Ahn, J.; Choon Shim, "Progressive multi gray-leveling: a voice spam protection algorithm,"
Network, IEEE, vol.20, no.5, pp.18-24, Sept.-Oct. 2006.

[11] MjSIP VoIP Client

http://www.mjsip.org/mjua.html

©Informatics '09, UM 2009 RDT6 - 240