An anti-spam device - introduction

Notes about the feasibility of an anti-spam phone calls device.

Spammers.
Any day there is always somebody, or somewhat, that place a call to advertise the last offer for a credit card, or to sell the latest life insurance or who knows what else.

Unless to pay for some provider options, usually expensive, the main weapon against these pests, is the caller-ID.

Often is enough to see the number to identify the caller as spammer.
But sometime the number is "local", one of the many tricks spammers use to make more hard to identify a spam call.
Instead to use a 1 800 or 1 888 or other "free" or "commercial" numbers, they use local numbers, to trick the users.
Because of that, the second weapon against these pests, is the answering machine.
With that, you can "screen" the incoming call and identify a spammer or a real call.

The third weapon is our hand.
Everytime an incoming call is recognized as spam, is enough to off-hook the handset and then on-hook it, just to avoid to have the phone ringing and/or a useless and annoying message be put on the answering machine.

But since I'm lazy ... why don't build an appliance capable to do what I normally do ?

The idea is to have an appliance capable of screen the incoming calls and eventually close calls coming from known spammers.
It can not prevent the 100% of spammers to annoy with the calls, but it can limit the disturb.

How it works

The idea is quite simple.
Everytime an incoming call arrive, the system reads the caller ID and compare it with an internal data base.
If the number or name is recognized, the system will pick up (off-hook) and immediately put down (on-hook), closing the incoming call.
Or alternatively, the system can go off-hook, play a message and then on-hook.

If the number is NOT recognized, the system will wait for the user to push a button.
The last received number will be retained, so at any moment pressing the pushbutton, the number will be stored and put in the search list, if not already present.
From the user perspective, if a call is coming from a spammer, will be enough to press a button to let the system to remember the offensive number.
After that, every call coming from that number will be answered by the system.
Of course the system is not 100% accurate because unfortunately some calls doesn't have any caller-ID associated or they have a generic "private" or "unknown" indication.
Some policies are necessary, with a set of limitations, to deal with these special cases.

Specifications

The system will be capable of :

• be connected to a PSTN phone line, POTS interface,  in parallel 
• be capable to recognize when an incoming call happens
• be capable to read the caller-ID of the incoming line
• to search in a database if the caller exists
• be capable to simulate the off-hook / on-hook and eventually to send a audio message on line
• be capable to "edit" the database contents (for example to remove a user put in black list)
• store information about incoming calls (date, hour, lenght of the call, ecc.)
• (optionally) have a LAN interface for management/remote administration

Architecture

The system is built around a processor and logical modules.
Every module describe the functionality, not how it is done.

 
Ring detector

The ring detector circuit, alerts the processor about an incoming call. 

Caller ID reader

The caller ID reader, is sending to the processor the data of the incoming call in ASCIIZ format.

Off-hook/On-hook circuit

The Off-hook/On-hook circuit allows to simulate the handset operation, forcing the line off-hook and on-hook.

Input/Output

At least a display and small keyboard will allow to interact with the appliance.
Depending the processor/platform used, a remote connection (serial/LAN/wireless/ecc.) could allow a computer to extract data/edit the database 

Possible systems

There are many different approaches in order to build such appliance.
The operations to do are simple enough to be executed by a small processor.
Any MCU capable to handle few I/O and having some comunication capabilities, is suitable to be used.
For example a PIC or Arduino or MSP430 can do the trick.

I have around a nice candidate for such project,  the Olimex board with the MSP430f169, that also has a SD card reader/writer, in order to store the phone numbers.
An Arduino board is probably the most efficient solution.

Another approach, is to use a ready made high level system, using maybe embedded Linux as main system.
For example the FriendlyARM board, that supply the processor/memory/user input/display functionality or a Beagleboard or similar card.

Another  board, connected using an RS232 port and I/O, can provide for the Caller ID reading capability, line detection and off-hook/on-hook functionality.

It is indeed quite an overshoot to use a board like the FriendlyArm, but assuming to have the development environment ready, it should be much more easy to build the system.
With such board become also feasible to create an interface to access the data remotely via web.

In any case a board with the POTS interface needs to be built and then interfaced to the system.
An old caller-ID kit is used for the caller ID functionality.

Mc145447 demo board

Centuries ago I bough a kit based on the Motorola MC145447 chipset.
This chip-set allows to decode the incoming caller-ID frame and extract it in ASCIIZ on a RS232 line.
The chip set also provide the ring detection circuit, in order to know if a call is incoming.

Here the schematic of the ITU kit based on the MC145447.

Note that this chip-set is long out of production, but amazingly is still available !

POTS interface

Test #1
A board capable to handle all the POTS operation can be built, starting with the caller ID circuit.
Here a schematic of a test circuit to do the first experiments :

   


The transformer is used mainly to give the correct load when simulating the off-hook, but in future it is possible to use it to send audio messages on line.
For example is possible to simulate the "disconnected  tone" usually sent by the telco provider, in the hope that the calling system will stop to place calls.

Or, just to vent out some stress, to play bad messages toward the spammer :-)

The first tests are done on a breadboard with recycled components.
To the ITU Caller ID kit (the green PCB on the breadboard)  I attached an old modem transformer and a reed relay.
A push-button gives the signal to activate the relay (it will be replaced by a MCU I/O).

The first tests are positive. The circuit is connected to the phone line in parallel and when the phone is ringing, pressing the push-button the call is taken and then released, simulating the off-hook/on-hook operation.

Attaching an audio source to the other side of the transformer (see the plug) is possible to hear it on the remote phone when the system is on off-hook.

In the picture is visible also the Olimex board.

 
Test #2

The next step is to start to integrate the POTS interface toward the micro, in this case the MSP430F169.
The breadboard is more populated, with the addition of a voltage regulator, a more easy to use power switch and the Olimex board, with some signals hooked.
Also some signals from the MC145547 chipset are brought out.

Here a new schematic.

and a picture of the new populated breadboard.

For the moment the MC145547 chip (green board) is interfaced to a normal RS232 connector.
Note the Olimex board with some signals brought out.
The Olimex board will be usually powered by the JTAG, only for tests it can be powered (as in the picture) from the 5V regulator.

This is what I did so far, a very quick prototype to test the feasibility of the idea.

The next step is to build a more reliable circuit and choose the final board.
In the example, the Olimex board with the MSP430f169 was used but probably an Arduino or something Linux based it should be better and more flexible.
As usual I have to wait to find the time and resources to do it ...