TelecomsXchange contribution to FCC calling for a solution to end robo and spam calls

The Problem

Scam and robotic calls is a top concern for everyone. It is estimated that 50% of U.S. mobile traffic will be scam calls by 2019. Not only are unwanted calls annoying, they are potentially dangerous with unsuspecting citizens tricked into losing thousands of dollars to scammers and fraudsters.

Most of the provided solutions to people to avoid this problem have never been effective as simply people cannot only answer calls for known numbers, or simply just hangup. in fact users should never have to think about this problem, it is the responsibility of communication service providers to innovate to avoid this problem.

In this blog post I propose a realistic easy, scalable and secure solution to implement solution with collective efforts by all major network operators e.g T-Mobile, Verizon, AT&T … and for the FCC to force the policies.


TelecomsXchange has successfully disallowed robocalls to pass by its network for years now using even simpler solutions, by understanding how to the robo callers minds work + some creative code we were able to kill that type of traffic from hitting our network completely. From this place we think we can help contribute some ideas and thoughts with the community.

This solution is aimed to be real-time, quick to implement , does not require an update on handsets and every different sip hardware or software out there or creating any new load on the networks, and no immediate blockchain this time, Sorry guys 🙂 .

The database that maintains the records could be decentralized using blockchain at a later stage. For now let’s keep it simple.

CLID verification

First we have to solve the Caller Identification Spoofing issue, To do that first when a call comes to the service provider e.g from 954-240-xxxx to 786-xxx-xxxx the service provider needs to check IF  954-240-xxxx is 1-is real number and 2- is really calling 786-xxx-xxxx or not.

HLR lookups which already exists in all CSPs (Communication Service Providers) networks today can already tell if the caller id is real or not, second issue we remain to solve is if the caller-id sent is really calling the B number or not, to do that the service provide must do another lookup which doesn’t exist today to see if caller is really dialing the number.

For example:

Service provider receives a call from 954-240-xxxx =====> 786-xxx-xxxx , the steps it will need to take as follow:

1- Check if 954-240-xxxx is a real and verified number via HLR lookup. e.g {“status” = “verified”}

2- Check who does 954-240-xxxx belong too? e.g  {“carrier” = “AT&T”}.

3- Lookups IF 954-240-xxxx is calling to 786-xxx-xxxx on AT&T network e.g { }

This API call will basically check against AT&T’s records if the number 954-240-xxxx that belongs to its network is actually calling 786-xxx-xxxx  the B number. If it is AT&T returns the value TRUE the call is routed to the subscriber as usual, if not it will return  FALSE and the call is never sent to the number and rejected by the service provider or rerouted to a different path for an extra layer of verification like early media IVR captcha.

by implementing the caller-id verification lookup we are forcing the call generators (Spammers, RoboCallers) to basically must buy a real phone number or DID for every call they send which makes it very expensive and maybe not profitable  and the calls will be traceable back to them to them.

What carriers must do at their end ?

in order to check wether number A is actually calling number B every carrier must call a web hook each time a subscriber on their network is initiating a call so that the centralized or decentralized dB is updated with that information to verify if the claimed phone number is really making that call or not, this has to be a mandatory update by all operators that own 1 number or more in order to verify the call is real or not by gateways before routing the call to the termination gateway. Which is nice as it doesn’t require every gateway out there to be updated and aware of any new protocols which is not very realistic in our opinion.

Carrier will need to notify the new layer VLS ( verified lookup service) whenever a call is initiated with From and To fields so that all other operator can confirm the call was really made from that number or not. The concept of encryption and securing the way this data is stored is another topic that cryptography experts can comment on and contribute to. However every operator that owns numbers must obtain a digital certificate to verify their identity before they can communicate with VLS ( Verified Lookup Service)

Some ugly drawings ( will update better one soon)

We think a proof of concept can be implemented within 30-40 days if any party is willing to sponsor the R&D for this project.

If you have any questions about the proposed solution that might help you with your own solution please contact .